The APIThe problem: a client who wants a spreadsheet every Friday

Your clients can pull their own numbers.

A documented REST API for one client's own data: bookings, workers, timesheets, invoices and compliance. Their systems ask. TalentCore answers. Nobody builds a spreadsheet on a Friday afternoon.

Talk to us See how it works

9 read endpointsOne client's own records, as JSON.
2 writesSubmit hours, correct hours.
300 an hourPer key, counted in every response.

API keys Example Foods portal

Key	Scope	Expires	Last used
Finance system	Read only	9 Feb 2027	Today 07:00	Active
Time and attendance	Read and write	11 May 2027	Today 17:42	Active
Old reporting tool	Read only	No expiry	3 Aug	Revoke

Finance system key · Example Foods
Read only · expires in 90 days

07:00, every morning. Example Foods' finance system has its invoices. Nobody was asked for a spreadsheet.

GET/api/v1/invoices200 OK

{
  "data": [{
    "invoice_number": "INV-00318",
    "invoice_date": "2026-11-13",
    "week_ending": "2026-11-15",
    "net": 9456.00, "vat": 1891.20,
    "gross": 11347.20,
    "status": "sent"
  }],
  "meta": { "page": 1, "per_page": 50, "total": 1 }
}

Response headersX-RateLimit-Limit: 300X-RateLimit-Remaining: 299

Screens are drawn from the real product with made-up data.

How a client connects

Nothing can arrive by API that a person could not have typed.

Hours sent by a client's system meet the same checks as hours keyed into the client portal. The API is another door into the same room, not a way round it.

1KeyIssued by their admin
2ReadTheir data, only theirs
3WriteHours in, shift by shift
4CheckThe queue a person uses

Step 1

The problem: a shared login nobody can switch off

Clients create their own keys

Issued by their admin. Revoked in seconds. A person on the client's side decides a key exists, what it may do and when it stops working. Your team is told every time, and can see every request it makes.

In the API section of the client portal, a client admin names a key, chooses read only or read and write, and sets an expiry. The key is shown once, to be copied into their system. Integration becomes something a client can start the same day, with no ticket to your IT.

Expiry: none, 30 days, 90 days, 6 months or 1 year.
Up to 10 live keys for each client.
Your team is alerted when a key is created or revoked.

API keys Example Foods portal

What is this key for?Finance system

Expires90 days

What it may do Read onlyLook at your bookings, workers, timesheets, invoices and compliance position. Change nothing.Read and writeAs above, and submit and amend timesheet hours.

Create key

Your new key Copy it now. It is shown once.

Example Foods created an API keyRead only, expires in 90 days. Sent to your team.

Step 2

The problem: clients ring you for their own figures

Nine things a client's system can ask for

Account, sites, bookings, the workers placed with them, weekly timesheets, shift-level timesheet entries, invoices, compliance position and a health check. Compliance comes back as a status and an expiry date. The documents themselves stay with you.

Their data. Only theirs. Every key belongs to exactly one client. The client is taken from the key, never from anything the caller sends, so there is no parameter that could ask for somebody else's records.

The client portal shows the same data to people

Endpoints

GET/accountThe organisation this key belongs to
GET/sitesYour sites
GET/bookingsYour bookings
GET/workersWorkers placed with you
GET/timesheetsYour weekly timesheets
GET/timesheets/entriesShifts, and which are open for hours
GET/invoicesYour invoices
GET/complianceStatus of the workers supplied to you
GET/healthHealth check

Step 3

The problem: the same hours keyed into two systems

One shift, one set of hours

Hours in, from their system to yours. A read and write key can do two things: submit the hours for a shift, and correct hours the client entered. Nothing else in TalentCore is writable from outside.

The client's system lists the shifts that are open for hours, then sends the paid hours for each one. The shift is found from the worker and the date on that client's own account. A worker who is not on one of their bookings gets the same answer as a worker who does not exist.

GET/timesheets/entries

Kay D. · Thu 12 NovW-01042 · Depot 1
Open
Mo O. · Thu 12 NovW-00933 · Depot 2
Open
Raj K. · Thu 12 NovW-00871 · Depot 1
Recorded
Kay D. · Fri 13 NovW-01042 · Depot 1
Pending

POST/api/v1/timesheets201 Created200 OK

{
  "worker_ref": "W-01042",
  "date": "2026-11-12",
  "hours_worked": 7.5,
  "break_minutes": 30,
  "note": "Signed off on the site sheet"
}

Recorded. 7.5 hours for Kay D., Thursday 12 November, Depot 1.

Sent again after a timeout? Same figures, so nothing is written twice. The answer says it was a replay.

Step 4

The same queue a person uses

Hours sent by API land where hours keyed in the client portal land, and every line says where it came from. Your team checks them like any others. A large client can automate its timesheets end to end without widening what a key can touch.

Every line shows its source: the worker, the site clock or the client.
Hours arrive ready to check, with no rekeying.
Every write is logged again in the audit trail.

Where the hours go next

Worker	Site	Hours	Source	Status
Raj K.	Depot 1	8.0	Clocked at site	Approved
Tia F.	Depot 1	8.0	Worker	To approve
Kay D.	Depot 1	7.5	Client	Approved by client
Mo O.	Depot 2	9.0	Client	Approved by client

Kay D., 7.5 hours. Sent by Example Foods' own system at 17:42. Same checks as the portal grid.

What else it does

The rest of the contract.

For their integrator
Conventions they already knowVersioned, paginated, one error shape
A link, not a meetingOpenAPI and a docs page
Safe to retryNever silently overwritten
Refused, with the reasonEvery failed field listed
For whoever holds the keys
Scoped, expiring, hashedRevoked, then refused
Every request on the recordLogged, limited, alerted

Conventions an integrator already knows

The version is in the path. Status codes mean what they usually mean. Every error has the same shape. Lists are paginated and tell you the total. It follows the UK government's published API standards, which matters when the buyer is a council or a large enterprise.

Dates are ISO 8601, and timestamps are in UTC.
50 results a page by default, up to 200.
The limit and what is left of it come back in the response headers.

GET/bookings?page=2200 OK

{
  "data": [ 50 bookings ],
  "meta": { "page": 2, "per_page": 50, "total": 146 }
}

GET/invoices401

{
  "error": {
    "status": 401,
    "code": "unauthorised",
    "message": "..."
  }
}

One error shape, everywhere. A code for the machine and a sentence for the person reading the log.

Hand their IT team a link, not a meeting

The API is described in OpenAPI and served with a documentation page a person can read. An integrator can generate a client from the specification or read the contract end to end, without contacting you first.

The specification is served from the API's own address, beside the docs page.
Their admin creates the key in the portal, so they can start the same day.

/api/v1/openapi.yaml

openapi: 3.1.0
paths:
  /bookings:
    get:
      summary: Your bookings
  /timesheets:
    post:
      summary: Submit the hours for one shift

SSam, Example Recruitment10:12To: IT, Example Foods

Your API documentation

The docs page and the specification are at the same address.
Your admin creates the key in the portal.

Open the documentation

Safe to retry. Never silently overwritten.

A shift can only hold one set of hours. Repeat the same figures and nothing changes. Send different figures for a shift that already has hours and the API refuses, so a second system cannot quietly change what the first one sent. A correction is its own, deliberate call.

The same figures again: nothing is written, and the answer says it was a replay.
Different figures: refused. The first set stands.

POST
The same figures againNothing written. Marked as a replay.
200
POST
Different figures, same shiftRefused. The first set stands.
409
PATCH
A correction to hours the client entered7.5 becomes 8.25, with a note saying why.
200

POST/api/v1/timesheets409

{
  "error": {
    "status": 409,
    "code": "hours_already_recorded",
    "message": "Hours are already recorded for that shift..."
  }
}

Refused, with the reason

Unknown fields are rejected, not ignored. When a submission fails, every field that failed is listed and nothing is written. Hours for a shift that has not finished, a cancelled booking, or a pay week past its cut-off are turned away with a sentence saying what to do instead.

Every failed field comes back at once, so the integrator fixes them in one go.
Each refusal carries its own code.

POST/api/v1/timesheets422

{
  "error": {
    "code": "validation_failed",
    "details": { "fields": [
     { "field": "hours_workd", "code": "unknown_field" },
     { "field": "break_minutes", "code": "break_exceeds_hours" }
    ] }
  }
}

Nothing was written. Both problems come back at once, so the integrator fixes them in one go.

The shift has not finishedshift_not_finished409
The booking was cancelledbooking_cancelled409
The pay week is past its cut-offpay_week_closed409

Scoped, expiring, and stored as a hash

A key is read only unless someone chose otherwise, and nothing in a request can widen it. TalentCore keeps only a one-way hash, so a lost key is revoked and reissued, never recovered. Revoke one and the very next request using it is refused.

2 scopes: read only, or read and write.
Each key has its own name and expiry.
A key is shown once, when it is made.
Up to 10 keys live at once for each client.

API keys Example Foods portal

Finance systemExpires 9 Feb 2027 · last used today 07:00
Read onlyActive
Time and attendanceExpires 11 May 2027 · last used today 17:42
Read and writeActive
Old reporting toolNo expiry · last used 3 Aug
Read onlyRevokeRevoked

GET/api/v1/bookingswith the old key401 refused

Only a one-way hash of each key is kept. A lost key is revoked and reissued.

Every request on the record

Each request is logged with its status and how long it took, and every write is logged again in the audit trail. A burst of failed authentication raises a security alert for your administrators. Limits stop a single client flooding the service, or a leaked key minting more.

300 requests an hour for each key. Past that, a clear "try again in" answer.
At most 5 keys issued for a client in 24 hours.
The limit and what remains are in the response headers.

How the rest of TalentCore is secured

Time	Request	Key	Status	Took
17:42:08	POST /timesheets	Time and attendance	201	84 ms
17:42:09	POST /timesheets	Time and attendance	201	79 ms
18:03:30	GET /invoices	Unknown key	401	6 ms
18:03:31	GET /invoices	Unknown key	401	5 ms
18:03:31	GET /workers	Unknown key	401	5 ms

API authentication failuresA spike from one address. Raised for review.

Webhooks and notifications

TalentCore listens as well as answers.

3 routes

Mail, messages and clock events reach TalentCore the moment they happen. Forged ones are refused at the door.

Branch mailbox09:14:02
Application: picker, days

Applicants09:14:03
Dom K. filed, CV attachedNew

Mail captured in about a second

Microsoft 365 tells TalentCore the moment mail lands in a connected mailbox. Applications and client emails are filed while the person is still interested, not on a polling delay.

Mailbox subscriptions renew automatically.
WhatsApp reply
Signature checks outAccepted

Unsigned request
Claims to be a replyDiscarded

Signed messages only

WhatsApp replies and events from a connected clocking service arrive by signed webhook. One is only accepted when its signature checks out, so nobody can post a fake reply into a worker's record.

Unsigned or wrongly signed requests are discarded.
Teams · Branch channel05:14
Unfilled booking alert
Example Foods (BK-00412) on Thu 12 Nov still needs 1 worker.

Events posted to a Teams channel

TalentCore can post the events you choose into a Microsoft Teams channel: a booking still short of workers, a document about to expire, an invoice gone overdue.

This is the outbound notification that exists today.

Deliberately not here

What the API will not do.

3 limits

Not a door into the whole CRMCandidate pipelines, margins and other clients cannot be reached. The API is scoped to one client's own data, on purpose.
Not a way to change anything elseTwo writes exist: submit hours and amend hours. Bookings, rates and worker records are changed by people, in TalentCore.
Not a webhook subscription serviceThere is no general-purpose outbound webhook product. Clients poll the API, and your own team can have events posted to Teams.

Why it matters

Their systems fetch. Their people still sign off.

For recruiters and for leaders

For recruiters

No more Friday spreadsheets.

Clients pull their own figures instead of asking you for an export.
Hours arrive ready to check, with no rekeying.
If a client's key leaks, it is revoked in seconds.

TalentCore for recruiters

For business leaders

A real answer to "can it integrate?"

Enterprise and public sector buyers can connect their automation and case management tools.
Documented, standards-based integration shortens procurement questionnaires.
Least-privilege access you can evidence to an auditor.

TalentCore for business leaders

The specifics

The contract, exactly.

8 rules

For the integrator who wants the limits before the sales call.

300an hour: Requests for each key. The limit and what remains are in the response headers.
50 / 200: Results a page by default, and the most you can ask for.
2scopes: Read only, or read and write. Read only is the default.
10keys: Live at once for each client, each with its own name and expiry.
5in 24 hours: The most keys that can be issued for one client in a day.
ISO 8601, in UTC: Every date and time, in every response.
A one-way hash: All that is stored of a key. It is shown once, when it is made.
OpenAPI: The specification is served from the API's own address, beside the docs page.

How it connects

The same records, through another door.

6 links

Tell us what your client's system needs to know.

Send us a line and a person who knows recruitment will answer it. Bring the integrator's questions. We would rather answer them early.

Talk to us info@talentcorecrm.com

Your clients can pull their own numbers.

API keys Example Foods portal

Nothing can arrive by API that a person could not have typed.

Clients create their own keys

API keys Example Foods portal

Nine things a client's system can ask for

One shift, one set of hours

The same queue a person uses

The rest of the contract.

Conventions an integrator already knows

Hand their IT team a link, not a meeting

Safe to retry. Never silently overwritten.

Refused, with the reason

Scoped, expiring, and stored as a hash

API keys Example Foods portal

Every request on the record

TalentCore listens as well as answers.

Mail captured in about a second

Signed messages only

Events posted to a Teams channel

What the API will not do.

Their systems fetch. Their people still sign off.

No more Friday spreadsheets.

A real answer to "can it integrate?"

The contract, exactly.

The same records, through another door.

Tell us what your client's system needs to know.