--- title: "Snowflake: batch resolve, 500 rows a request" summary: "This is an integration pattern over the HTTP API, not a shipped connector. There is no package, no managed application, no marketplace listing and nothing to install: what is described below is the shape of the integration you would build, written down because knowing the shape in advance is most of the work. The warehouse route is the batch endpoint: unload the rows you want resolved, post them in requests of up to 500 records, and load the results back, joining on your own key — it travels through the pipeline as a client reference and comes back on every row. Everything below assumes your Snowflake account can reach an external HTTPS endpoint, which is an account-level decision somebody in your organisation has to make before any of this starts." canonical_url: https://entitybind.com/integrations/snowflake last_updated: 2026-10-12 copy: full --- # Snowflake: batch resolve, 500 rows a request > This is an integration pattern over the HTTP API, not a shipped connector. There is no package, no managed application, no marketplace listing and nothing to install: what is described below is the shape of the integration you would build, written down because knowing the shape in advance is most of the work. The warehouse route is the batch endpoint: unload the rows you want resolved, post them in requests of up to 500 records, and load the results back, joining on your own key — it travels through the pipeline as a client reference and comes back on every row. Everything below assumes your Snowflake account can reach an external HTTPS endpoint, which is an account-level decision somebody in your organisation has to make before any of this starts. Canonical page: https://entitybind.com/integrations/snowflake Last updated: 2026-10-12 ## Entity Bind and Snowflake Pattern over the HTTP API This is an integration pattern over the HTTP API, not a shipped connector. There is no package, no managed application, no marketplace listing and nothing to install: what is described below is the shape of the integration you would build, written down because knowing the shape in advance is most of the work. The warehouse route is the batch endpoint: unload the rows you want resolved, post them in requests of up to 500 records, and load the results back, joining on your own key — it travels through the pipeline as a client reference and comes back on every row. Everything below assumes your Snowflake account can reach an external HTTPS endpoint, which is an account-level decision somebody in your organisation has to make before any of this starts. - What this is: A pattern you build - Steps to working: 4 below - Limits: 5 below - Written back to your systems: Nothing - To install: Nothing at all Before you build any of it: The answers land on your own rows before any code does, and looking costs no integration work. [Start free →](https://app.entitybind.com/app?signup=1) By [James Rooney](https://entitybind.com/about), founder of Entity Bind · Last revised 12 October 2026 ## How you get a key Create your workspace online and verify your email, then create your own read or resolve API keys, each shown once and revocable. Free includes 300 credits and needs no card. Paid subscriptions are purchased through Stripe in Billing, with applicable VAT and no automatic usage or overage charges. `host.example.com` is a placeholder everywhere below, and a client configured against it will not connect. The hosted base URL is https://app.entitybind.com. Replace the placeholder with that origin; registry checks follow your activated plan. The full-pipeline evaluation is arranged separately and is not activated by signup. Request it for your workspace; we confirm availability, sources and the start date before activation. It starts with a conversation about your file. Create your workspace online, verify your email and create your own API key. Free includes 300 credits and shallow matching with no card; choose a paid subscription in Billing when you need registry checks. [Start free →](https://app.entitybind.com/app?signup=1) ## What you would build for Snowflake There is nothing to install, so the blocks below are the job itself: the query, the request, and the branch on what comes back. Endpoint paths, header names and field names are the API's own and are exact — the code around them is a shape to fit to your own stack. ### 01 Decide what leaves the warehouse Send the identifying columns and the key you want back, and nothing else. A resolve needs at least one identifying field — a name, a website, a domain, an email, a phone, a registration number, an LEI, a VAT number, a D-U-N-S, an ISIN, a ticker, or previous and trading names — and a request carrying none of them is rejected with a 422 before anything runs. Country and postcode do not count: they narrow an identity rather than being one, so a row carrying nothing but a country has asked no question. ### 02 Unload, in batches of 500 The batch endpoint takes up to 500 records per request, treats them as an unordered set, recognises a repeated idempotency key as the same request rather than a new one, and writes one ledger row per outcome rather than a single summed row. It is not a queue: batches run one at a time, so a 300,000-row table is an overnight window to plan rather than a throughput figure to assume. Size the job around that before you promise anybody a refresh schedule. ``` -- The shape of what leaves the warehouse. Your key rides along as -- client_ref and comes back verbatim on every row, so the result set -- joins to this table on your own identifier rather than on ours. SELECT account_id AS client_ref, account_name AS name, website AS domain, billing_country AS country, billing_postcode AS postal_code FROM analytics.crm.accounts WHERE account_name IS NOT NULL; ``` ### 03 Post the batch One request, up to 500 records, and an idempotency key so that a retry after a network failure does not pay twice. depth sets how far through the stages a record may go and defaults to research; setting it to probabilistic caps the spend and turns what would have been deep answers into abstentions rather than into cheap guesses. ``` curl -sS -X POST "$ENTITYBIND_BASE_URL/v1/batch" \ -H "Authorization: Bearer $ENTITYBIND_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: crm-accounts-2026-09-02-part-001" \ -d @batch-001.json ``` ### 04 Load the results back, including the ones that did not resolve Three result sets rather than one, and it is the second two that are worth modelling properly. Resolved rows carry an entity id, a confidence and a decision id. Abstentions carry a typed reason, a ranked shortlist and the column that would have decided — that is your work list, and it is free. A new entity minted because nothing matched is a third thing again: it is not a match, the number it carries is not a calibrated match confidence, and it must never be folded into an accepted-match count. If a step above fails against your own deployment, send us what the client reported rather than working around it. [Talk to us →](https://entitybind.com/contact) ## What this route gets you Every surface runs the same pipeline: the same cascade, the same confidence floor, the same evidence and the same credit rule. These are the things this route adds on top of it. - Deduplication stated in your own identifiers: rows are grouped by the entity they landed on and labelled with your key values, so the answer is "these six of your rows are one company", in the ids your warehouse already uses. - A per-row reason for every unresolved record, and a named column to add or repair wherever a column is nameable — which is most rows and not all of them. - A decision id per row that reopens the full evidence trail at a URL, so a merge that a table now depends on can still be explained a year later. - Per-field licence and provenance columns from the export endpoint, so a downstream table can be filtered to what you are permitted to redistribute rather than to what happened to arrive. ## What it will not do Start with the first one: it decides whether there is anything to install at all. The rest are the parts of the shape that most often get scoped wrong. 01. This is an integration pattern over the HTTP API, not a shipped connector. There is no package, no managed application, no marketplace listing and nothing to install: what is described below is the shape of the integration you would build, written down because knowing the shape in advance is most of the work. 02. No native application, no external function template, no Snowflake Marketplace listing and no share. If your platform team's answer to outbound HTTPS from the warehouse is no, this route is closed, and the way round it is to unload to object storage and call the API from wherever your jobs already run. 03. Batches run one at a time. A 300,000-row file is an overnight window, and there is no rows-per-second figure to quote because none has been measured. 04. Nothing is written back to your warehouse. We hand you result sets and loading them is your job, which is the right division of labour for an operation that is irreversible in your systems and reversible in ours. 05. The batch path bills like every other surface: one credit for a decision reached at the deterministic or probabilistic stage, five for one that needed adjudication or research, nothing for an abstention at any stage, nothing for a byte-identical replay, and nothing for an input that normalised to no identifying signal. Check these integration limits before building. Create your Free workspace to inspect your own rows and keys; contact us if you need help choosing a supported integration shape. [Start free →](https://app.entitybind.com/app?signup=1) ## The other ways in 3 of the 6 are shipped integrations and 3 are patterns over the HTTP API. Every card says which kind it is, so you know what you are scoping before you open it. - [Claude Code](https://entitybind.com/integrations/claude-code) (Shipped): 4 steps · 4 named limits - [Claude Desktop](https://entitybind.com/integrations/claude-desktop) (Shipped): 4 steps · 4 named limits - [Cursor](https://entitybind.com/integrations/cursor) (Shipped): 4 steps · 3 named limits - [Salesforce](https://entitybind.com/integrations/salesforce) (Pattern): 4 steps · 5 named limits - [Python](https://entitybind.com/integrations/python) (Pattern): 4 steps · 5 named limits Snowflake sits with Salesforce and Python on the same shelf: nothing to install. If you are weighing a shipped integration against a pattern, [the line between the two shelves](https://entitybind.com/integrations#the-line) is drawn on the hub. Whichever surface you land on, the cheapest first move is the same: a few hundred of your own rows. [Start free →](https://app.entitybind.com/app?signup=1) ## What to read next The work this surface is installed to do, the method behind the answers it returns, and the terms those answers use. Each card names its own shelf. - [Master data management](https://entitybind.com/use-cases/master-data-management) (Use case): An independent admission policy beside the platform you already run. - [Supplier master and accounts payable](https://entitybind.com/use-cases/supplier-master-and-ap) (Use case): Duplicate vendors, remittance conflicts and concentration you cannot see. - [How to deduplicate a supplier master](https://entitybind.com/guides/how-to-deduplicate-a-supplier-master) (Guide): Duplicate vendors, payment leakage, remittance conflicts and parent concentration. The accounts payable playbook for finding which vendor records are one company, with a citation for every finding. - [Survivorship and golden records](https://entitybind.com/guides/survivorship-and-golden-records) (Guide): Merging records is only half the job. Field-level survivorship, source precedence, temporal facts, per-field provenance, and why last-confirmed beats first-seen. - [Entity resolution for data analysts](https://entitybind.com/guides/data-analyst) (Guide): Profile the columns, normalise without manufacturing merges, resolve, work the exceptions, then ship a crosswalk and a golden-record view. The warehouse-side playbook for company rows with no shared key. - [Abstention](https://entitybind.com/glossary/abstention) (Definition): An abstention is a first-class 'we do not know' returned instead of a match: the record comes back unresolved, with a ranked shortlist, a typed reason and the column that would have decided it. - [Idempotency](https://entitybind.com/glossary/idempotency) (Definition): An operation is idempotent when performing it repeatedly has the same effect as performing it once, which is what makes a retry after a timeout safe rather than duplicating work. - [Replay](https://entitybind.com/glossary/replay) (Definition): Replay is re-serving a previous decision for byte-identical content rather than recomputing it, which makes repeated submissions free and deterministic — provided the replayed decision is still one the system would stand behind. - [Content fingerprint](https://entitybind.com/glossary/content-fingerprint) (Definition): A content fingerprint is a hash of the meaningful content of a submitted record, used to recognise that the same thing has been sent before regardless of when, in what order, or under what key. ## Start with a file, not an integration. Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration. [Start free](https://app.entitybind.com/app?signup=1) · [Read the API docs](https://entitybind.com/api) 300 credits. No card. For a guided review of your file, explore [the Merge Safety Sprint](https://entitybind.com/audit-pack). ## Questions about Snowflake ### Is there a Snowflake connector? No. There is no native application, no external function template, no Marketplace listing and no data share. What exists is a documented HTTP API with a batch endpoint that takes 500 records a request and echoes your own key on every row — enough to build the integration in a working day, if your account is permitted to make outbound calls. Scope it as build time on your side rather than as something to install. ### How long does a large table take? Plan a window rather than a rate. Batches run one at a time rather than being queued and fanned out, so a 300,000-row table is an overnight job to schedule. What the file contains changes the cost far more than its size does: rows that already carry a company number or an LEI settle at the deterministic stage for one credit each, with no model calls at all, while a table of bare names reaches the stages that spend. --- Internal fixtures only. The historical 2026-08-29 per-tier recording covers 317 GB companies with identifier-rich arrivals seeding the catalogue first; the context tier includes country and registered-town prose. Its legacy replay has no full-prompt-verified calls and cannot certify current calibration. The September 5 CI reports cover 1,176 labelled pairs and 705 records over 250 companies using offline stubs. These are not independent customer holdouts or live production validation; the 99% minimum-input product target remains unmet. Scope is company and organisation identity only — not people, vessels, bank-account ownership, sanctions or emissions. Results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. This is the Markdown copy of https://entitybind.com/integrations/snowflake, assembled from the same data the page renders and carrying every sentence, table row, figure and question the page's main content carries. The HTML page is canonical; it adds the layout, the navigation and the interactive parts (the ask panel, the forms), which a copy can name but not run. Every page on the site, with a line on each: https://entitybind.com/llms.txt.