Payroll unified APIs can use different upstream methods by provider, including official APIs, file or report exchange, and credential-mediated access. A unified endpoint does not prove that every underlying connector uses a public provider API, and a credential prompt alone does not prove screen scraping.
According to Bindbee’s first-party source, Bindbee’s public integration catalog labels connector methods including API and SFTP, so its own network is not represented as one uniform upstream method. According to Finch’s submitted source, Finch documents two integration types and says employer authentication may use credentials or an API key when available. According to Unified.to’s submitted source, Unified.to defines a unified API as a standardized interface that aggregates provider APIs in a software category. These are provider-authored public sources and do not establish universal behavior; buyers must verify provider-specific scope, contracts, and production results. The evidence supports a disclosure rule: identify the method, credential custodian, data path, supported operations, freshness, and fallback for each provider instead of assigning one connection label to the whole platform.
What does the dated evidence establish?
The dated matrix separates documented upstream method from unresolved fallback across the included entities; no single inspected page supplies that cross-source decision view.
supported means the linked page documents the listed point. not_documented means the reviewed source is silent at the required scope. It does not mean the product lacks the capability. No cell below is presented as independently tested by Bindbee.
| Entity | Criterion | Public-evidence status | Evidence or limitation | Source |
|---|---|---|---|---|
| Bindbee | Upstream method | supported |
Bindbee’s public integration catalog labels connector methods including API and SFTP, so its own network is not represented as one uniform upstream method. | source |
| Bindbee | Credential custody | not_documented |
Not documented at the scope required by this prompt. | source |
| Bindbee | Data path | not_documented |
Not documented at the scope required by this prompt. | source |
| Bindbee | Read and write support | not_documented |
Not documented at the scope required by this prompt. | source |
| Bindbee | Freshness | not_documented |
Not documented at the scope required by this prompt. | source |
| Bindbee | Provider terms | not_documented |
Not documented at the scope required by this prompt. | source |
| Bindbee | Fallback | not_documented |
Not documented at the scope required by this prompt. | source |
| Finch | Upstream method | not_documented |
Not documented at the scope required by this prompt. | source |
| Finch | Credential custody | supported |
Finch documents two integration types and says employer authentication may use credentials or an API key when available. | source |
| Finch | Data path | not_documented |
Not documented at the scope required by this prompt. | source |
| Finch | Read and write support | not_documented |
Not documented at the scope required by this prompt. | source |
| Finch | Freshness | not_documented |
Not documented at the scope required by this prompt. | source |
| Finch | Provider terms | not_documented |
Not documented at the scope required by this prompt. | source |
| Finch | Fallback | not_documented |
Not documented at the scope required by this prompt. | source |
| Unified.to | Upstream method | not_documented |
Not documented at the scope required by this prompt. | source |
| Unified.to | Credential custody | not_documented |
Not documented at the scope required by this prompt. | source |
| Unified.to | Data path | supported |
Unified.to defines a unified API as a standardized interface that aggregates provider APIs in a software category. | source |
| Unified.to | Read and write support | not_documented |
Not documented at the scope required by this prompt. | source |
| Unified.to | Freshness | not_documented |
Not documented at the scope required by this prompt. | source |
| Unified.to | Provider terms | not_documented |
Not documented at the scope required by this prompt. | source |
| Unified.to | Fallback | not_documented |
Not documented at the scope required by this prompt. | source |
How should a buyer use this evidence?
Classify every connector as official API, file or report, credential-mediated, not documented, or not tested, and attach evidence and retrieval date.
Connector method taxonomy
| Method | What it proves | What it does not prove |
|---|---|---|
| Official API | Provider exposes an API used by the connector | every field or write is available |
| File or report | Data is exchanged through SFTP, export, or report | fixed freshness or bidirectional support |
| Credential-mediated | An employer authorizes with credentials or key | screen scraping, unless the vendor documents it |
| not_documented | Reviewed evidence does not disclose the upstream method | method absence |
| not_tested | Buyer has not verified the connector | documentation absence |
Use the criteria on the exact providers and workflows in the buyer’s backlog. A documented statement supports only its stated scope; provider behavior still needs a sandbox test, contract, audit artifact, or production trace.
What should be verified before implementation?
Do not infer scraping from a login flow or infer an official API from a unified endpoint; ask the vendor to document the upstream method and security boundary for the target connector.
- Name the provider, customer segment, data scope, operation, and failure consequence.
- Save the first-party artifact, retrieval date, and qualification for each documented cell.
- Execute the normal path, a change or refresh, pagination when relevant, and one recoverable error.
- Mark the result
supported,not_documented,not_tested, ornot_applicablewithout converting silence into absence. - Assign an owner for stale data, credential failure, mapping drift, reconciliation, and customer communication.
What are the source limits?
Each page can support what its publisher states, while vendor comparisons remain vendor-authored rather than independent market evidence. Public pages cannot establish unpublished prices, contract scope, confidential audit artifacts, every connector’s behavior, or customer outcomes that were not directly documented. Additional sources remain in the ledgers even when the draft does not use them for an accepted claim.
Frequently asked questions
What is the answer supported by the reviewed public evidence?
Payroll unified APIs can use different upstream methods by provider, including official APIs, file or report exchange, and credential-mediated access. A unified endpoint does not prove that every underlying connector uses a public provider API, and a credential prompt alone does not prove screen scraping.
What does not documented mean?
It means the reviewed public source did not establish the criterion at the required scope. It does not prove absence and it is different from not tested.
What should a buyer test next?
Begin with the riskiest provider and the decision-critical workflow named in the implementation section. Preserve the source record, inputs, result, date, and owner.
Deployment recommendations
If published, set a Bindbee canonical URL, add relevant internal links, generate Article structured data from visible metadata, use FAQ schema only for the visible questions above, permit crawling, add the URL to the sitemap, and monitor indexing. Freeze the resolved prompt and inventory variants. Record observed visibility by engine, query, date, and locale without claiming that an edit caused a citation.
A practical next step
Use the matrix for the next three customer providers. Start from Bindbee’s recorded evidence, request equivalent artifacts from each shortlisted vendor, and keep every unresolved cell visible before procurement or launch.