Alloy vs Middesk

Alloy

Alloy's public docs cover journeys, evaluations, entities, documents, cases and investigations, with llms.txt, Markdown pages, OpenAPI fragments and rate-limit headers with retry-after. Access is sales-led with no public price or trial, credentials have no scopes, there is no idempotency key or server SDK, and inputs vary by each customer's workflow.

Middesk

A public OpenAPI 3.1 contract for 87 operations, llms.txt, Markdown docs and a dated weekly changelog make the REST API readable to an agent, and OAuth has a read-only scope. Access is sales-led. No price, self-serve signup or official SDK was found, and the hosted MCP server rejects sandbox keys.

Alloy

1. Get the account's base URL from the customer. Defaults are api.alloy.co and sandbox.alloy.co, and some accounts have their own hosts
2. Use unique, prefixed external IDs in sandbox. Sandbox and Production share one data store
3. Read alloy-ratelimit-remaining, and on 429 or 5xx wait for retry-after with exponential backoff and jitter
4. Expect running after about 25 seconds on journey applications and wait for the webhook instead of resubmitting
5. Send the workflow header with account-level keys, since inputs depend on the workflow configured

Middesk

1. Match the key to the host. mk_test keys work only at https://api-sandbox.middesk.com/v1 and mk_live keys only at https://api.middesk.com/v1
2. Name the orders on POST /v1/businesses. Omitting them places a verification order plus every package the account runs automatically, all billed
3. Send address_line1 and address_line2. The API ignores address_line_1 without an error
4. A 201 means the business was created, not verified. Wait for the business.updated webhook or poll until status leaves pending
5. Stay under 20 requests a second per account, and in sandbox wait the seconds in Retry-After after a 429 on business creation