Integrations

Connected to the systems you already run

Card issuance sits downstream of your directory and upstream of your access control. A platform that cannot talk to both just moves the re-keying somewhere else. CardOffice provisions over SCIM, signs people in through your identity provider, exposes a REST API with webhooks, encodes RFID into access control, and syncs with your own databases.

Talk through your stack Request a free trial See the platform

Outbound only

How the sync connects

Sources
Microsoft SQL Server, MySQL, PostgreSQL, or CSV files
Direction
The agent dials out. Nothing on the internet reaches in.
Credentials
Held on site. No database login shared with a hosted service.
Status
Running in production against a live SQL Server student-records system
Data sync

Sync with the database you already run

Not every card programme starts from a directory. Many run from a student-records or HR database with no API, on a server IT will not expose to anything. CardOffice syncs with it directly: Microsoft SQL Server, MySQL or PostgreSQL, or CSV files for systems that can only export.

A small agent sits beside your data, picks up what has changed on a schedule you set, and maps it onto cardholders. Tables, views or your own queries, field mappings, filters and timing are all configurable, so the sync fits the way your data already moves instead of forcing a new one. Card details and photographs can flow back the other way, so your records system stays complete.

  • Your schema, not ours. Map any table, view or query onto cardholder fields.
  • Both directions. Cardholders come in; card details and photographs can be written back.
  • No hard switch-off date. Both systems stay current, so moving across is not a single terrifying weekend.
Directory provisioning

SCIM, straight into the cardholder roster

Entra ID and Google Workspace provision automatically over SCIM. A new starter appears in the roster ready to be photographed. A name or department change flows through on the next provisioning cycle. A leaver's card deactivates itself. No CSV exports, no re-keying, and no card office finding out about a departure three months late.

  • Configurable field mapping. Employee number, department, and holder type, student, staff, contractor, visitor, all map from your directory's own fields, rather than from a schema we decided on.
  • Adopts, rather than duplicates. Matching is deliberate, so provisioning attaches to the cardholders you already have instead of creating a second record beside each one.
  • Deactivation is part of it. Deprovisioning in the directory is what shuts off the card, so access ends when employment does.

SCIM 2.0

What flows through

Identity
Given name, family name, preferred name, primary email
Organisation
Employee or student number, department, holder type
Lifecycle
Create, update, deactivate, on your provisioning cycle
Direction
Directory to CardOffice; the directory stays the source of truth

Separate concerns

Two jobs, two settings

Single sign-on
Who is allowed to log into the portal, and how they prove it
SCIM provisioning
Who is in the cardholder roster, and whether their card is live

Configured independently. Use either, or both.

Access

Enterprise login, enforced per organisation

Single sign-on through Entra ID, Google Workspace or Okta, over OpenID Connect, with two-factor authentication enforced at the organisation level rather than left to each user's good intentions.

Single sign-on and SCIM are complementary but genuinely separate. One governs the portal, the other governs the roster. Turning on SSO does not silently start rewriting your cardholder list, and turning on SCIM does not change how staff log in.

  • Role-based access inside each organisation, so a photo reviewer is not a billing administrator.
  • Every action audit-logged with who, when, and what changed.
API

A REST API and webhooks, in production

Not a roadmap item and not a partner-only extra. The API is how the platform talks to itself, which is the only version of an API worth handing to somebody else.

REST API

Full coverage of card holders, cards, orders and photos. Secured by scoped API tokens, so an integration gets exactly the access it needs and nothing beyond it.

Webhooks

Real-time events on every status change: a photo approved, an order released, a card printed, a credential revoked, so your systems find out when it happens rather than on the next poll.

Built to extend

The same interfaces are what we use to reach enterprise systems. If you have something else in the stack, the conversation starts from a working API rather than a proposal.

Public verification

Every card and wallet pass carries a verification code that checks against the live system. Anyone can confirm an ID is genuine and still current in seconds, the part a photocopy cannot reproduce.

Access control

RFID encoding, configurable rather than fixed

Encoding is the point where an ID card stops being a photograph with a name on it and starts opening doors. CardOffice encodes RFID through a configurable interface, so the credential format is something you set rather than something you inherit.

It works with access control systems by writing the door credential to the card's chip at an encoding station, then reading it back to confirm it before the card is handed over. Magnetic stripe encoding is built in on supported printers, and runs as part of the same print job rather than a second pass at a second machine.

  • Works with access control systems. The door credential is written to the chip, read back to check it, and recorded against the cardholder.
  • Configurable interface for the encoding format, not a single hard-coded scheme.
  • Mag-stripe built in on Zebra ZXP-series printers, encoded during the print run.
Printing and encoding
Staff ID Encoded
A. Cardholder
RFID · MAG · QR
Deployment

Hosted by us, or hosted by you

Where the records live is a deployment choice, not a paid tier of trust. Nothing is withheld from the self-hosted build to make the hosted one look better.

Hosted by CardOffice

Hosted in New Zealand. We patch it, back it up nightly with encrypted off-site copies, and publish a status page. Most institutions start here, because it is the shortest path to issuing a card.

Hosted by you

Deployed inside your own infrastructure or your own cloud tenancy. Cardholder records and photographs never leave the boundary your policy draws, and your team holds the keys, the backups and the upgrade window.

Either way the controls are the same: tenant isolation, audit logging on every action, instant revocation of a card and its wallet pass, role-based access with single sign-on, and retention periods you set. Photographs are never used for facial recognition and never used to train models.

Common questions

Frequently asked

Do we need SCIM and single sign-on, or just one?

Either, or both. They do different jobs and are configured separately. SCIM keeps the cardholder roster in step with your directory. Single sign-on controls who can log into the portal. Plenty of organisations start with SSO for staff and add SCIM once they are ready to retire their spreadsheet.

Which identity providers are supported?

Single sign-on works with Entra ID, Google Workspace and Okta, over OpenID Connect, with two-factor authentication enforced per organisation. SCIM provisioning runs from Entra ID and Google Workspace.

Will provisioning create duplicate records for people we already have?

No. Matching is deliberate rather than naive, so provisioning adopts the cardholder records you already hold instead of creating a second one beside them. Field mapping is configurable, so employee number, department and holder type come from your directory's own fields rather than a schema we picked.

Can CardOffice sync with our own database?

Yes. The sync agent works with Microsoft SQL Server, MySQL, PostgreSQL or CSV files, maps your tables, views or queries onto cardholders, and can write card details and photographs back. It makes outbound connections only, so there is no inbound firewall rule to justify and no shared database credential to hand out. It runs in production today against a live student-records system.

Can we drive card issuance from our own systems?

Yes. The REST API covers card holders, cards, orders and photos, and the webhook system raises real-time events on every status change. Access is by scoped API token. It is tested and running in production, and built to extend into the enterprise systems you already run.

Bring us your stack

Tell us which directory you run, what your access control is, and what the card office is stuck with today. We will tell you honestly which parts connect now and which parts would be new work.

Book a consultation See how it works in five steps