Proxy
Sign in Request access
Menu
Request access Sign in

Modular business infrastructure

The services behind work that gets done.

Separate services you embed in your own applications. Take one or take several. They share one credential model, one audit trail and one meter.

Request access See how it fits together

A worked example using an invented organisation, Northgate Adjusters: a claim document is stored, read, turned into a settlement letter, signed, sent to the customer, and recorded. Six Proxy services, one audit trail.
In Customer upload 3 pages · 2.4 MB · pdf
  1. Storage storage.upload stored
  2. Processor ocr.document extracted
  3. Documents documents.generated generated
  4. Sign esign.envelope signed
  5. Communications communications.email_sent delivered
  6. Record usage + audit recorded
Out Signed settlement letter 6 audit entries · 5 usage records

Capture to proof, as one connected model.

Prove is not another service you buy. It is what the other five stages produce while they run.

Choose a lifecycle stage

Something arrives

Files, forms and messages enter from wherever the work starts.

Your page mounts a Proxy component with a short-lived token your own backend minted. The limits shown to the person are the limits Proxy enforces, because both are read off that token rather than out of page code.

  • Browser uploads through a single-capability client session
  • Forms completed and submitted against a resource you name
  • Inbound email and SMS recorded against the same record
  • Addresses resolved at the point of entry, before bad data lands

Delivered by

Storage Communications Address Lookup

Evidence it leaves

A stored object with the actor, the resource and the byte count.

It is understood

Text extraction, classification and checks turn a file into fields.

Processing is asynchronous and metered per page or per document. You get a job you can poll or a webhook you can trust, and the same operation key appears on the usage record you are billed for.

  • Optical character recognition, per page or per document
  • Classification of what the document is
  • Extraction of the fields you asked for
  • Identity and document verification where the work needs it

Delivered by

Processor Identity

Evidence it leaves

A job with a terminal state, and one usage record per unit processed.

It is kept properly

Managed objects with storage class, metadata and a size ledger.

Objects belong to an organisation, not to a bucket you have to secure. Storage class is explicit, from standard through to deep archive, and every size change is a ledger event rather than a recalculated total.

  • Six storage classes, from standard to deep archive
  • Metadata you define, queryable alongside ours
  • A size ledger, so a bill can be explained after the fact
  • Deletion that stays reversible until it does not

Delivered by

Storage

Evidence it leaves

A ledger entry for every size and lifecycle event on the object.

People are scheduled

Availability, appointments and bookings against real constraints.

Booking is the stage where your customer and your team meet, so it runs in the browser on a token scoped to one booking, and the appointment it creates is attached to the record the work already lives on.

  • Availability published from the constraints you set
  • Appointments booked by the customer, in your page
  • Bookings attached to the record, not to a calendar silo
  • Changes and cancellations recorded rather than overwritten

Delivered by

Calendar

Evidence it leaves

A booking event with who booked it, when, and against what.

The work is done

Documents generated, signatures captured, messages sent.

This is the stage that leaves your organisation. An envelope puts a document in front of somebody outside the business over your name, so it is enabled deliberately rather than switched on by default.

  • Documents generated from your templates
  • Signature envelopes through draft, sent, opened, viewed, signed, completed
  • Drawn and typed signatures, validated server-side
  • Email and SMS sent on the organisation's behalf

Delivered by

Documents Sign Communications

Evidence it leaves

An envelope status history and a delivery record per message.

It can be shown

Every operation above leaves a record you can hand to somebody else.

Prove is not a service you buy. It is what the other five stages produce as they run: a named actor on every mutation, a usage record with the operation and the unit, a delivery outcome, and a signature verdict.

  • A named actor on every mutating operation
  • Usage records carrying the operation key, quantity and unit
  • Webhook events with a delivery status, retried and recorded
  • Signature validation verdicts kept with the signature

Delivered by

The platform itself

Evidence it leaves

The audit trail, the usage ledger and the delivery record.

Eight services. Each one does a single job.

Add a capability without rebuilding the system you already run, one service at a time.

  • Storage

    Hold the file, and account for it.

    Feeds Processor, Sign and Documents

  • Processor

    Turn a document into fields.

    Reads from Storage, feeds Documents

  • Sign

    Get a document signed, and preserve the evidence.

    Signs from Documents, delivered by Communications

  • Documents

    Produce the document itself.

    Fills from Processor, signed by Sign

  • Calendar

    Find a time and hold it.

    Confirmed by Communications

  • Communications

    Send it, and record that it was sent.

    Carries Sign, Documents and Calendar

  • Identity

    Confirm the person is who they say.

    Runs beside Processor

  • Address Lookup

    Get the address right the first time.

    Validates before Storage

All eight, with scopes and metering

Two calls, and the evidence they leave.

The last tab is the half most integration pages leave out: what the operation recorded about itself, without anybody asking it to.

Choose a code sample

app/Http/Controllers/EvidenceController.php

use Proxy\ProxyClient;

// Read from configuration. Never in the repository, never in a browser.
$proxy = new ProxyClient(
    secretKey: config('services.proxy.secret'),
    organisation: config('services.proxy.organisation'),
);

$file = $proxy->storage()->upload(
    file: $request->file('evidence'),
    metadata: ['claim' => $claim->reference],
);

// A job, so this returns as soon as the work is accepted. The
// idempotency key is yours: only you know which retry is which.
$job = $proxy->processor()->analyse(
    file: $file->id,
    tasks: ['ocr', 'classify', 'extract'],
    idempotencyKey: "claim-{$claim->id}-evidence-{$file->id}",
);

$job->state;   // 'queued'

Two calls. The second returns before the work is finished.

resources/js/evidence.js

import { PoweredByProxy } from '@proxy/browser';

const proxy = new PoweredByProxy({
    publishableKey: 'pk_live_...',
    baseUrl: 'https://api.proxy.example',
});

// The uploader takes no maxFiles option. Its limits are read off the
// token your backend minted, so the page cannot widen them.
await proxy.storage.mountUploader({
    token: clientToken,
    target: '#evidence',
});

A token for one capability and one claim. A secret key never reaches the page.

GET /api/v1/processor/jobs/01k5m8f2...

{
  "data": {
    "id": "01k5m8f2r7q0x3v9tzcd4npb6h",
    "state": "completed",
    "operation": "ocr.document",
    "file": "01k5m7z4h9c1e8ptw2yb3rkq5d",
    "tasks": ["ocr", "classify", "extract"],
    "result": {
      "classification": "invoice",
      "pages": 3,
      "fields": {
        "invoice_number": "INV-40912",
        "issued_on": "2026-08-14",
        "total": "1284.60"
      }
    },
    "usage": { "quantity": 1, "unit": "document", "cost": "15p" },
    "actor": { "type": "integration", "name": "Claims portal" },
    "completed_at": "2026-08-14T09:41:07+00:00"
  }
}

The fields you asked for, the operation you were charged for, and the actor.

GET /api/v1/audit?resource=01k5m7z4...

{
  "data": [
    {
      "event": "storage.object.created",
      "resource": "01k5m7z4h9c1e8ptw2yb3rkq5d",
      "actor": { "type": "integration", "name": "Claims portal" },
      "recorded_at": "2026-08-14T09:40:58+00:00"
    },
    {
      "event": "processor.job.completed",
      "resource": "01k5m8f2r7q0x3v9tzcd4npb6h",
      "usage": { "operation": "ocr.document", "quantity": 1, "status": "charged" },
      "recorded_at": "2026-08-14T09:41:07+00:00"
    }
  ]
}

The same two calls from the evidence side. The half that matters six months later.

Developer overview API reference (opens a different site)

Mechanisms, not assurances.

One set of controls in place of point integrations that each solved this differently.

Isolation is structural

Every record belongs to one organisation. A request carrying another organisation's identifier is refused while the route is still being resolved, before a line of application code runs.

The answer is 404, not 403, because a 403 would confirm the record exists.

A scope narrows. It never grants

An integration holds scopes, and its effective permission is the intersection of those scopes with what its owner can already do. A credential cannot be configured into an authority nobody has.

Entitlement is asked separately, on every request, from the scope itself.

Every mutation has a named actor

The actor is not optional and not derived. It is written to the audit trail and onto the record itself, so the question "who did this, and when" has an answer that does not depend on log retention.

The same authorisation model serves the API and the web interface.

Retention, residency and the rest

Three shapes of work, from one catalogue.

Between them they compose six of the eight services. Evidence is preserved as the work happens rather than assembled afterwards.

Claims handling

Turn a folder of photographs into a decision

A customer uploads what they have from a phone. Proxy reads it, works out what each file is, and keeps the originals with the extraction beside them.

Services used, in order: Storage then Processor then Storage

Evidence
Original file, extraction job, and the actor on both.

Legal operations

Generate the document, then get it signed

Fields already held on the matter populate your template. The document is stored, sent as an envelope, signed in the browser and returned to both sides.

Services used, in order: Documents then Sign then Communications

Evidence
Envelope status history, signature verdict, delivery record.

Field services

Book the visit inside your own product

Availability comes from the constraints you publish. The customer picks a slot in your page, and the appointment attaches to the job rather than to a calendar nobody else can see.

Services used, in order: Calendar then Communications

Evidence
Booking event with who, when and against what.

Two more, on the platform page

Start with one service.

Tell us what the work is and we will set up an organisation, issue test keys and enable the one service you need first. Nothing is metered until you turn something on.

Request access Read the API reference

To begin
One organisation, one integration, test keys
To add a capability
A second scope. No change to the first service
To account for it
Every cost traces to the operation that caused it