❮ Integrations

Company API

Your client grants access to your company, and your own app gets an Open button. No keys travel through chats, and every opening is signed with the name of the employee who pressed it.

Who this is for: services whose employee has to drive into a closed yard — nannies and tutors, cleaning, mobile tyre fitting and car washing, courier and delivery, nursing and lab visits at home. The client keeps the barrier they already have; you get a button instead of a phone call to the client at the gate.

How it works

In your interface the client says they need to drive in. You check two things first: the barrier opens on a call from the client's number, and the client's phone stays online. If the barrier has an Entrixy controller, the phone is not needed at all.
You create a request and show its QR code. The client scans it, installs the app, adds the barrier and grants access — your company is already waiting in the list.
You open by API, naming the employee. The client sees the opening in the log with that name and can take access back in one tap.

The key never exists as a link. Your company receives a reference to it, not the key itself, so there is nothing to copy or forward; the key is bound to your account and works only through this API. Passing access on to an employee is not possible — that is deliberate, and it is what makes the client comfortable granting it.

Authentication

There are two ways in, and the difference is what the client sees.

Signature bound to your domain

You publish a public key on your own domain and sign every call with the private one. We take the key from the domain itself, so the right to call and the right to be shown under that domain are the same thing: the file disappears, the domain moves or changes hands — the calls stop at once. There is no one-off "verified" tick to outlive reality.

https://<your domain>/.well-known/entrixy.json

{ "key": "<Ed25519 public key, 32 bytes, base64>" }

The pair is made on your side; we never see the private half. Two commands are enough:

openssl genpkey -algorithm ed25519 -out entrixy-private.pem
openssl pkey -in entrixy-private.pem -pubout -outform DER | tail -c 32 | base64

The second one prints the string for the file. The first one leaves the private key with you: it signs every call, and there is nowhere to send it.

Then each request carries four headers:

X-Entrixy-Org:   your-domain.com
X-Entrixy-Ts:    1750000000          // unix seconds, ±300 s
X-Entrixy-Nonce: 0011…ff             // 32 hex, used once
X-Entrixy-Sig:   <base64>            // Ed25519 over the base string

base = "<domain>.<ts>.<nonce>." + sha256(raw request body)

A repeated nonce is refused, and so is a body that does not match the signature. This is the mode where the client sees your domain and your logo.

A domain written in national characters goes into the header and into the base string in its punycode form — xn--… — the same form it takes in the address of the key file. The client is still shown the readable spelling.

Signing in PHP, for example, is four lines:

$body  = json_encode($payload, JSON_UNESCAPED_UNICODE);
$ts    = time();
$nonce = bin2hex(random_bytes(16));
$base  = "$domain.$ts.$nonce." . hash('sha256', $body);
$sig   = base64_encode(sodium_crypto_sign_detached($base, $secretKey));

$secretKey here is the 64-byte private key of the pair, the one openssl left with you.

A secret, if you have no domain

Register, issue a secret in the cabinet and put it in the body. Your calls work the same, but the client is shown only the name you wrote for yourself, with a note that the domain is not confirmed — no logo, no domain. As soon as the key appears on your domain the secret stops working: otherwise a leaked secret would speak in the name of a confirmed company. So start with a secret if you like, and switch to the signature when you are ready — not the other way round.

POST https://entrixy.com/api/company.php?a=<action>
Content-Type: application/json

{ "org_id": 17, "secret": "…", … }

Creating a request

POST /api/company.php?a=request
{ "org_id": 17, "secret": "…", "ref": "order-517", "ttl_hours": 72 }

→ { "code": "rrGzNweV31rkHV6Q",
    "url":  "https://entrixy.com/c/rrGzNweV31rkHV6Q",
    "expires_in_hours": 72 }

ref is your own order number, it comes back in the status. Put url into a QR code and show it to the client.

State of the request

POST /api/company.php?a=status
{ "org_id": 17, "secret": "…", "code": "rrGzNweV31rkHV6Q" }

→ { "state": "issued", "key_ref": 4821, "ref": "order-517",
    "claimed_at": "2026-09-09 12:20:11", "issued_at": "2026-09-09 12:24:03" }

State	Meaning
`new`	the QR code has been created, the client has not arrived yet
`claimed`	the client opened the app — they are on the way
`issued`	access granted; `key_ref` is what you open with
`revoked`	the client took the access back
`expired`	the request expired before the client arrived

Opening

POST /api/company.php?a=open
{ "org_id": 17, "secret": "…", "key_ref": 4821,
  "number_id": 93, "actor": "Ivan P., shift 12" }

→ { "ok": 1 }

actor is mandatory: it is what the client sees in the log. Anything that identifies the employee for you will do — a name, a badge number, a shift. Without it the call is refused.

Answer	Meaning
`403 forbidden`	this key is not yours, or the object is not in it
`403 revoked`	the client took the access back
`403 expired`	the key's lifetime is over
`400 actor_required`	the employee was not named
`429 rate_limit`	too many openings on one key per minute

Your card in the app

Send us the name and a square logo when your company is registered. The client sees them on the page they scan, on the consent screen and next to every line in the log — so it is clear who is being let in. The logo is served from our side; we do not pull images from other hosts.

Getting started

Register the company in your account — it takes one form and starts working straight away. The domain, the secret, the callback address, the logo and the list of requests all live in the company cabinet.

Company account