Core Objects

Most integrations are built from a small number of objects. This guide explains what each one is, why it exists, and how they relate to each other. If you are looking for the definition of a single term, see the Glossary.

A Client is the person you're working with. Each distinct reason for verifying them is created as a Case — the unit your team works and signs off. Within a case you send one or more Records to the client, each requesting something specific from them. A record contains one or more Steps: the individual checks or pieces of information you're asking for. Each record is linked into its case by a Case Item, which tracks what the case contains and when each record was added. A Record Template is a reusable blueprint that saves you rebuilding the same set of steps every time.

Every case belongs to a client, and every step belongs to a record. Cases are the default structure, though a small number of legacy teams are not yet on this model. One important difference from the product: the API does not put records into cases for you — see Creating a record inside a case takes two calls.

Terminology

The API and the Amiqus application use different names for the same things. The API terms are the ones used throughout this documentation and in every request and response.

API term	Amiqus term	What it is
Client	Person	The individual being verified.
Case	Case	A grouping of records covering a single process.
Record	Request	A set of steps sent to a client to complete.
Step	Check, document request, document transfer or form	One unit of work within a record.
Record template	Request template	A saved set of steps and settings used to create records.

See the Glossary for the full list, including files, documents and organisations.

The objects

Client

A client is the person your team wants to engage with — a candidate, applicant, employee or customer. It holds their name, contact details and any information gathered about them over time.

A client is the anchor for everything else: records and cases both belong to a client, and a client persists across as many of them as you need. Create one with Create a client.

Record

A record is a set of steps you ask a client to complete. It is the object your client actually interacts with: creating one produces a perform_url that the client opens in a browser to work through the steps.

Records carry an email and a name that are snapshots taken when the record was created, so they may differ from the client's current details if those have since changed. A record also has its own status reflecting how far the client has progressed, and an expired_at date after which it can no longer be completed.

Create one with Create a record.

Step

A record consists of one or more steps, and a step is the smallest unit of work. Steps come in four kinds:

Step type	Purpose
check.*	A verification performed by Amiqus or a provider, such as check.identity, check.criminal_record or check.watchlist.
document.request	Asks the client to upload a document.
document.transfer	Sends a document to the client to read or sign.
form	Asks the client to answer a set of questions.

Only one of each check type may be used within a single record. Steps are reviewed individually, and each review has its own status independent of the record. See List all steps for a record.

Case

A case represents one distinct reason for verifying a client — an onboarding, a contract renewal, a periodic re-verification — and groups the records that relate to it. It exists so that your team works and signs off the reason, not the person.

Without cases, a client who is checked twice two years apart has two unrelated records and no way to distinguish the first sign-off from the second. A case draws a boundary around one of those processes, gives it a name and optional reference, and gives your team a single status and a single place to review every result inside it.

Cases have their own assignees and a review history recording each status change and who made it. Create one with Create a case.

Case item

A case item is the membership link between a case and one record inside it. It carries an entity describing what it points to — an id and a type, currently always record — and its own created_at, recording when the record was added to the case rather than when the record itself was created.

You will rarely model case items directly, but they are how records are added to a case — see Adding a record to a case.

Record template

A record template is a saved set of steps and settings, so you do not have to describe the same combination of steps on every request. Templates are configured by your team in Amiqus and are read-only over the API.

Pass a template ID when creating a record instead of listing steps individually, and optionally have the template's assignees applied to the new record automatically. See List all record templates.

How they fit together

Creating a record inside a case takes two calls

Cases are created empty. There is no way to create a record and attach it to a case in a single request, and no case field on Create a record.

Adding a record to a case

Records are attached after the fact with Update items for a case, which merges the given items into the case's existing items:

[
    {
        "id": 8811,
        "type": "record"
    }
]

The same call is how you attach a follow-up record to a case later on. A case can gain further records at any point.

The link is one-directional

You can traverse from a case to its records, by expanding items on a case or by listing its case items. You cannot traverse the other way. A record has no case property, and records cannot be filtered by case.

If your integration needs to know which case a record belongs to, store that association on your side when you make the call that creates it.

Case status and record status are different

The two statuses answer different questions, are drawn from different enums, and do not track each other. A record's status describes how far one client has got through one set of steps. A case's status describes where your team is in reviewing the whole process.

Case status	Amiqus term	Meaning
awaiting_response	Waiting for response	Awaiting a response from the client, a provider or another external party.
action_required	Action required	Awaiting team member action to progress the case.
reviewed_pending_decision	Reviewed	Every check has been reviewed; pending final approval or rejection.
approved	Approved	Completed and approved.
rejected	Rejected	Completed and rejected.
on_hold	On hold	Inactive, on hold.

pending also appears in the enum but is deprecated.

Case status moves in response to the checks inside the case, and it is not necessarily linear: a case that reached reviewed_pending_decision returns to awaiting_response if a further record is sent to the client. Team members can also set a status manually. Do not assume a case only ever moves forwards.

Record statuses are a separate enum entirely — pending, started, complete, waiting, paused and others — documented on the record object.

Availability of cases

Cases are the default, but the API will not apply them for you

Cases are the default structure for teams. A small number of legacy teams are not yet on this model and work with clients and records only; the cases endpoints are not available to them.

More important for your integration: a record you create through the API does not belong to a case until you explicitly add it. Records are never placed in a case automatically, even on a team that uses cases. Attach them with Update items for a case, and store the association on your side if you need to look it up later.

Next steps

• Pagination and Expandable Properties — how to retrieve these objects efficiently.
• Webhooks — how to be notified when records and cases change.
• Glossary — the full list of API terms and their Amiqus equivalents.