GovTech Provider Infrastructure

GovTech Provider Management API

The Aigistry Provider Management API allows approved GovTech Providers to manage account information, contact details, address, and API keys through API endpoints rather than a separate Aigistry dashboard.

API-Based Account Management

Providers already operate their own dashboards, administrative systems, and customer support environments. The Provider Management API exposes account-management functions so they can be integrated directly into existing provider systems.

One Account Endpoint

Your organization info, primary contact, and address all live on a single Provider record and are managed through one endpoint — no separate contact or address resources to keep in sync.

Provider-Owned User Experience

Account visibility, key management, and contact/address updates can be surfaced inside your own administrative environment.

Protected Authority Records

Authority Records represent your own client relationships. You may edit their name, type, website, or location, and suspend or reactivate them at any time — Aigistry does not gate these decisions.

Provider dashboard → Provider Management API → Aigistry account data
→ Provider-owned administrative experience.

Every endpoint on this page operates in Test or Live mode — see the dedicated Sandbox Mode documentation for how mode is determined and what stays fully isolated between them.

Management Boundary

The Provider Management API separates provider-level administration from verified Authority Record and platform-level control.

Providers Can Manage

  • Website and internal notes
  • Contact name, email, and phone
  • Address
  • API key creation and disablement, in either Test or Live mode
  • Authority Record details (edit name, type, website, city, state, country on records you own)
  • Authority Record status (suspend / reactivate your own)
  • Publication and publish-attempt history (read-only)

Providers Cannot Directly Modify

  • Provider status (Pending / Active / Suspended / Rejected)
  • Provider code
  • Historical National AI Feed records
  • Cryptographic proof fields
  • Published feed entries
  • Another Provider’s Authority Records, under any circumstance

This boundary allows providers to manage their own account relationship while preserving the integrity of verified Authority Records, provenance signals, timestamps, public feed entries, and cryptographic signatures.

Base URL & Authentication

Most Management endpoints use the same X-API-Key header as every other Provider API request — no separate credential, no token exchange. API Key management is the one exception: listing, creating, and disabling your own keys all require an authenticated Provider dashboard session instead, since a Provider must be able to create their first key before any key exists to authenticate with. 

https://feed.aigistry.com/api/provider/

Header: X-API-Key: naf_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Account

Retrieve or update your Provider account — organization info, contact, and address together on one endpoint. status and provider_code are read-only here; status changes are an Operator responsibility.

GET / PUT account.php

Example GET Response

{
  "success": true,
  "data": {
    "provider": {
      "id": 2,
      "provider_name": "Island Software",
      "provider_code": "ISLAND",
      "status": "Active",
      "website": null,
      "notes": null,
      "contact_name": "Jane Doe",
      "contact_email": "jane@islandsoftware.example",
      "contact_phone": "813-555-0100",
      "address_line_1": null,
      "address_line_2": null,
      "city": null,
      "state_province": null,
      "postal_code": null,
      "country": "United States",
      "approved_at": "2026-07-06 21:28:53",
      "created_at": "2026-07-06 21:28:53",
      "updated_at": null
    }
  }
}

Example PUT Request — Contact and Address Together

{
  "website": "https://islandsoftware.example",
  "contact_name": "Jane Doe",
  "contact_email": "jane@islandsoftware.example",
  "contact_phone": "813-555-0100",
  "address_line_1": "456 Main Ave",
  "city": "Tampa",
  "state_province": "FL",
  "postal_code": "33601"
}

Send any subset of updatable fields — you don’t need to include fields you aren’t changing. contact_email is validated as a real email format before it’s saved. Your account itself has no Test/Live distinction — this endpoint always reflects the same Provider record regardless of mode.

API Keys

Providers may list, create, and disable their own API Keys. A newly created key’s full value is shown exactly once, in the response — it cannot be retrieved again afterward. To rotate a key, create a new one and disable the old one; there is currently no single combined “roll” action.

GET api-keys.php

List all API Keys (masked — never returns the key value). Returns both Test and Live keys together by default — this is the one endpoint on this page that is intentionally not mode-siloed, since managing your full key inventory is an account-settings concern, not a “which environment am I working in” concern. Add ?mode=test or ?mode=live to filter to one mode only.

POST api-keys.php

Create — Example Request

{ "key_name": "Production Key" }

Create — Example Response

{
  "success": true,
  "data": {
    "id": 2,
    "key_name": "Production Key",
    "status": "Active",
    "is_test": false,
    "api_key": "naf_live_7f72ab8a...bfbc75cd7",
    "note": "This is the only time the full key is shown. Store it securely."
  }
}

The key you receive is generated in whichever mode your dashboard’s Test Mode toggle is currently set to when you click Create — visible immediately in the key’s own prefix (naf_test_ or naf_live_), not just the is_test field.

DELETE api-keys.php?id=2

Disable a specific key. Only Active keys can be disabled.

This endpoint requires a logged-in dashboard session, not an API Key — a Provider must be able to create their first key before any key exists to authenticate with.

Authority Records

List your Authority Records, edit the details of one you own, or suspend/reactivate one when a client agency’s engagement ends or resumes. Each Authority Record is fully owned by the Provider that created it — its name, type, website, and location fields belong to that Provider alone, so an edit can never affect another Provider’s record.

GET authority-records.php

List all of your Authority Records. Add ?id=X to retrieve one, or ?status=Active to filter. Unlike API Keys, Authority Records are fully mode-siloed — a request made with a Test key only ever sees Test Authority Records, and a Live request only ever sees Live ones. There is no way to view both together from a single call.

Example Response

{
  "success": true,
  "data": {
    "authority_records": [
      {
        "id": 1,
        "provider_id": 2,
        "provider_authority_id": "Tampa 01",
        "authority_name": "City of Tampa",
        "authority_type": "City",
        "website": "https://tampa.gov",
        "city": "Tampa",
        "state_province": "FL",
        "country": "United States",
        "status": "Active",
        "is_test": false,
        "notes": null,
        "created_at": "2026-08-06 21:06:24",
        "updated_at": "2026-08-06 21:06:24"
      }
    ],
    "total": 1,
    "is_test": false
  }
}
PUT authority-records.php?id=1

Edit any subset of authority_name, authority_type, website, city, state_province, country, provider_authority_id on a record you own.

POST authority-records.php?id=1&action=suspend

Suspend one of your own Authority Records. No request body needed.

POST authority-records.php?id=1&action=reactivate

Reactivate a previously suspended Authority Record.

A request in the wrong mode for a given id is treated as 404 Authority Record not found, the same response as an id that genuinely doesn’t exist — Aigistry never confirms a record’s existence in a mode the requester isn’t currently in.

Also Available (Read-Only)

Full detail on submitting Publications and idempotent retries is covered in the GovTech API Integration documentation.

Publications

GET publications.php lists your submitted Publications. GET publish-attempts.php lists every publish attempt, including failed ones with an error reason. Both are mode-siloed, same as Authority Records.

Activity Log

GET activity-log.php returns an audit trail of your own account actions — Authority Record changes and API key creation — each with a timestamp and detail. Also mode-siloed: your Test Mode activity and Live activity never appear in the same call.

Operational Guardrails

The Provider Management API is intentionally limited to provider-level management. It does not expose direct editing authority over another Provider’s records, Authority Record status outside your own scope, or public feed history.

Provider-Scoped Access

API Keys resolve to a single Provider. Management endpoints return or modify only records associated with that Provider.

Protected Fields Enforced Server-Side

Sending status or provider_code in an Account update request has no effect — those fields are never written from this endpoint, regardless of what’s submitted.

Historical Feed Integrity

Provider management endpoints cannot rewrite historical National AI Feed records, remove published records, or alter cryptographic proof fields.

The management layer supports provider autonomy without weakening Aigistry’s verification model. Providers manage their own account relationship and their own Authority Records; Aigistry preserves provenance integrity and National AI Feed continuity.

Implementation Support

GovTech Providers integrating account management workflows into their own systems may coordinate with Aigistry for deployment alignment, API testing, and operational implementation planning.

admin@aigistry.com
Scroll to Top