Beamery API guide 2026: access and 100Hires comparison - 100Hires

Beamery publishes an anonymously accessible Swagger API reference. This guide separates what developers can verify before a project from what an account team still needs to confirm.

API use is permissioned. Public support material describes an administrator-assigned API role, and OAuth clients and endpoint permissions involve Beamery Support.

We captured the public specification on July 16, 2026. It was Swagger 2.0 with 50 paths and 78 operations under /v1. It documented production endpoints, a US sandbox endpoint, authentication, resource methods, pagination, and rate limits.

Some buying questions remain outside that public record. The material we reviewed did not establish sandbox entitlement, API access by plan, webhook availability outside the public specification, or complete export and termination terms.

This article includes a disclosed comparison with the 100Hires API. 100Hires publishes it, so the comparison is owned-product analysis.

Key takeaways

• Public reference: Beamery's Swagger UI, specification, support pointer, and Postman page were accessible without login
• Permissioned use: account roles and support-led provisioning are documented, but enterprise-only or contract-gated access is not
• Environment: a US sandbox endpoint is documented; self-serve access and package entitlement are unknown
• Operating limits: 30 requests per second for authentication and 40 requests per second per company
• Change delivery: no webhook path appeared in the captured public spec, which does not prove that no separate webhook capability exists

What public developer evidence actually shows

We searched Reddit, YouTube, podcasts, X, and LinkedIn for first-hand accounts of building against, authenticating to, debugging, or operating the Beamery API. We did not find one qualifying API complaint in the corpus collected for this guide.

That is an evidence limit, not proof that implementation issues never occur. Broad product reviews, job posts, vendor announcements, and general Workday or SAP discussions cannot establish an API defect.

The practical result is a documentation-led evaluation. Claims that the API is enterprise-only, contract-gated, hidden behind login, or inherently difficult are not supported by the evidence we found.

Beamery API access: public reference, permissioned use

Public documentation and authenticated data access are different questions. Beamery's reference can be read anonymously. Protected API calls require credentials and role-based access.

The public Swagger documents one authentication operation. It exchanges Basic credentials for a token at GET /v1/auth.

Separate public prose mentions OAuth clients with endpoint permissions, but the captured Swagger exposes no OAuth operation. Confirm the current token URL with Support. The neutral OAuth 2.0 RFC describes the client-credentials model.

Beamery's public permissions material describes an API-only role assigned by an account administrator. OAuth clients, endpoint permissions, environment confirmation, and API-user setup involve Support or the customer success manager.

This is a permissioned provisioning process. It does not establish which commercial package includes the API, whether every account can obtain a sandbox, or whether an enterprise contract is required. Confirm those points for the specific account.

Five checks before building the integration

Define the system of record, sync direction, duplicate handling, and operational owner before building the integration. Then use the public spec to test the following five areas.

1. Confirm the environment and sandbox terms

The specification lists US production, US sandbox, and EU production endpoints. An anonymous request to a protected sandbox resource returned 403. That confirms a protected endpoint, not open test access.

Before scheduling development, ask which region your tenant uses, whether a sandbox is included, how test data is created, when data resets, and how closely sandbox behavior matches production. Confirm how credentials move between environments.

Write a small environment contract before coding. Record the base URL, tenant identifier, allowed data classes, refresh schedule, and named owner for each environment. This prevents a sandbox assumption from becoming a production delay.

Use representative but non-sensitive test records. Include duplicates, deleted records, missing fields, and records that change during a sync. Agree on the promotion test that must pass before production credentials are issued.

2. Choose authentication and permissions

The Basic-token route may suit a tightly controlled account integration. If Support provisions an OAuth client, define the required endpoint permissions and resource scope before coding.

Document the credential owner, secret store, rotation path, expiry or revocation behavior, audit trail, and emergency shutdown process. Apply least privilege instead of requesting every endpoint for convenience.

Build a permission matrix that maps each integration action to one endpoint and one business owner. A read-only reporting export should not receive the same access as a two-way candidate and vacancy sync.

Test the unhappy path too. Verify how the API behaves when a token is missing, expired, revoked, or valid but under-scoped. Capture the returned status and body so monitoring can distinguish an access change from a service failure.

3. Map resources to exact methods

The captured spec documents contacts, vacancies, applications, notes, users, pools, teams, attachments, access controls, and attract events. Contacts and vacancies expose create, read, PATCH update, and delete methods.

Do not assume that method coverage is uniform. The inspected application routes did not form full item CRUD. Notes use a less conventional combination, including an update-like POST on an item route. Check the exact operation needed for every workflow.

The 50-path and 78-operation counts describe the public surface on the capture date. They are not a score for completeness or quality, and they should not replace a method-by-method fit check.

For each row, write a contract test with a known input and expected output. Include required fields, enum values, timestamps, identifiers, and deletion behavior. This turns a broad endpoint inventory into evidence that the intended workflow can run.

4. Design pagination, throttling, and error handling

Beamery uses more than one pagination pattern. Several contact, user, vacancy, and pool lists use offset and limit. Some document a maximum page size of 200 and a 10,000 offset-plus-limit boundary. Notes use before, after, limit, and token parameters.

For larger contact synchronization, plan around the documented created-date or cursor-style approach rather than increasing offsets indefinitely. Save checkpoints so a failed run can resume without duplicating records.

The published limits are 30 requests per second for authentication and 40 requests per second per company. Build for 429 responses, monitor the documented rate headers, and use bounded retries with backoff and jitter.

Estimate calls per record before setting a schedule. A sync that lists contacts, reads details, fetches applications, and writes notes consumes several requests per person. Model peak batches and the daily average.

Keep authentication outside the record loop. Repeatedly requesting tokens can consume the separate authentication allowance and create avoidable failure points. Cache credentials only for their documented lifetime and rotate them through the agreed secret process.

The spec documents common 4xx and 5xx outcomes, but runtime error bodies can still vary by route. Test validation, unauthorized access, missing records, conflicts, throttling, and temporary failures with the actual account configuration.

5. Decide how changes move and how the integration exits

No path or description containing “webhook” appeared in the captured public Swagger. Ask Beamery whether event delivery exists outside that spec and, if it does, which events, signatures, retries, ordering, replay tools, and delivery logs are available.

If events are unavailable for the account, design a polling fallback with watermarks, idempotency keys, overlap windows, and reconciliation jobs. Decide which system wins when the same record changes on both sides.

Polling needs a completeness test. Compare source and destination counts, sample changed records, and re-read a recent time window to catch late updates. Alert on a stalled cursor, repeated page, growing backlog, or unexplained count gap.

Finish the design with procurement and exit questions. Confirm API entitlement, sandbox rights, support escalation, service levels, full data export, contract-end access, retention, deletion, and credential revocation in writing.

Ask for the answer in operational terms. “API access included” is less useful than a list of enabled environments, approved endpoints, rate terms, support contacts, export format, and the number of days credentials remain available after termination.

Beamery API vs 100Hires API

100Hires publishes this comparison. The 100Hires API covers recruiting workflows. Beamery presents a broader workforce and talent-intelligence platform. The documented surfaces overlap, but the products and object models are not equivalent.

Both vendors publish machine-readable references. The table uses specifications captured on July 16, 2026 and exact documented methods. Path and operation totals describe those references, not product quality.

The specification formats differ. Beamery's captured reference uses Swagger 2.0 and a /v1 base path. The 100Hires reference uses OpenAPI 3.1 and publishes its server base as https://api.100hires.com/v2.

100Hires documents CRUD for candidates, jobs, applications, and notes. Its company and job webhook routes support create, list, delete, and secret rotation. The spec includes a signing secret and the x-hires-signature-v2 header, but no update method or verified retry policy.

The resource comparison is strongest for recruiting workflows. Beamery's broader platform positioning and its public Workday and SAP pages are outside a one-to-one API parity claim. The tested 100Hires material did not establish native Workday or SAP SuccessFactors integration.

Treat the live OpenAPI document as the source of truth for webhook routes, schemas, and signing fields. The ATS webhooks page is a setup path. The live spec controls current technical details.

The rate limits use different units and scopes. Beamery documents 30 RPS for authentication and 40 RPS per company. 100Hires documents 100 requests per 10 minutes per key by default, and its guide says support can discuss removal for an integration use case.

Provisioning differs. Beamery documents an API role plus Support and customer-success steps. 100Hires documents key generation in Settings then Integrations and company verification.

The 100Hires API guide calls keys team-scoped; its OpenAPI description says user-company pair. The guide says API access is included on all plans at no extra cost. No public 100Hires sandbox was verified.

Practical go or no-go checklist

• Environment, region, and sandbox rights are confirmed
• Credential owner, permissions, storage, and rotation are defined
• Every required object has the exact read and write methods needed
• Pagination and expected data volume have been tested
• Rate budget, errors, retry ownership, and reconciliation are modeled
• Event or polling strategy and duplicate rules are agreed
• Support, entitlement, export, retention, and termination are confirmed in writing

Choose the API whose documented methods and operating model match the integration, not the one with the larger path count. If 100Hires is under consideration, book a demo to confirm current account access and implementation requirements.

Frequently asked questions

Is Beamery API documentation public?

Yes. Its Swagger UI, JSON specification, support pointer, and Postman page were anonymously accessible on July 16, 2026. The 100Hires API guide and OpenAPI JSON are public too. Both products require credentials for protected data.

How does Beamery API authentication work?

Beamery's Swagger documents a Basic-credential token route, and separate public prose mentions OAuth clients set up with Support. 100Hires uses a Bearer key. Its official sources differ on team versus user-company scope.

Does Beamery offer a sandbox API?

The public spec lists a US sandbox endpoint, but it does not establish self-serve creation or package entitlement. We did not verify a public 100Hires sandbox either, so confirm test-environment access before planning either integration.

What are Beamery's API rate limits?

Beamery documents 30 requests per second for authentication and 40 requests per second per company. 100Hires documents 100 requests per 10 minutes per key by default. Preserve the different units and scopes when modeling capacity.

Does Beamery's public API have webhooks?

No webhook path appeared in the captured public Swagger, but that does not prove no separate capability exists. Ask Beamery Support. By comparison, 100Hires documents company and job webhooks, including create, list, delete, secret rotation, and signing details.

Is Beamery API access included in a plan?

The public evidence reviewed here did not establish Beamery package entitlement. The 100Hires API guide says access is included on all plans at no extra cost, though its pricing page does not mention API entitlement.

How does the Beamery API compare with 100Hires?

Beamery documents a permissioned Swagger 2.0 API, a sandbox endpoint, 30 RPS for authentication, and 40 RPS per company. 100Hires documents an OpenAPI 3.1 recruiting API, CRUD for four core resources, signed webhook management, and 100 requests per 10 minutes per key by default.