Argyle vs Salsa

Argyle

Graded on the REST API. One OpenAPI file covers 91 operations, llms.txt indexes Markdown docs, and a Sandbox with sample users comes with a Console sign-up. Every payroll connection needs the worker to sign in through Link. No prices are published, no idempotency keys were found, and API keys carry no per-key scopes.

Salsa

Salsa is reached as an embedded-payroll partner, not through an employer's existing payroll account. The REST API has a public OpenAPI 3.1 spec with 123 operations, a payroll preview, a separate confirm step and short-lived user tokens limited by role. Access starts with a sales conversation, and no public price, self-serve sandbox, status page or API changelog was found.

Argyle

1. Send HTTP Basic auth with api_key_id as the username and api_key_secret as the password. Sandbox keys fail with 401 on Production and the reverse
2. Create the user with POST /v2/users and an external_id, then look it up by external_id before retrying. No idempotency key was found
3. Do not read data straight after an account connects. Wait for the account and data webhooks, or for the verification status, before fetching records
4. Follow the full URL in next when paging. Do not build cursor values or fetch pages in parallel. limit defaults to 10 and stops at 200
5. Stay under 50 requests a second. On 429, queue the request and retry later, not at once
6. Treat DELETE /v2/users/{id} as permanent. It removes every resource tied to that user, with no confirmation step

Salsa

1. Use the sandbox token against https://api.sandbox.salsa.dev and the production token against https://api.salsa.dev. Each environment has its own token
2. Call POST /payroll-runs/preview before creating a run, then confirm the PENDING run in a separate call. Confirming starts the employer debit
3. Send your own externalId on every create. A repeat returns a uniqueness error, which is the only duplicate protection
4. Make sure externalId values are unique across all employers, since each entity type has one namespace
5. Mint a user token with the lowest role and the fewest employerIds the task needs, and keep the partner token on the server