AU10TIX Results API

Retrieves the structured result of a verification session by its session/document identifier (polling with retry/backoff), returning the verification status (e.g. VERIFIED, FAILED, REVIEW) and the consolidated result payload.

Work with this as data

Every API here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for apis

7 MCP tools reach this
  • find_apisBrowse and filter every API in the catalog.
  • get_api_artifactsOne API's artifacts, grouped by type.
  • get_openapiThe primary OpenAPI for this API.
  • find_similar_apisAPIs that look like this one.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools

Call it yourself

curl for this page
This API
curl "https://apis.io/api/v1/apis/au10tix-results-api"
All apis
curl "https://apis.io/api/v1/apis?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no email required.

A second provider on the same verified email joins the account you already have.

OpenAPI Specification

au10tix-openapi.yml Raw ↑
openapi: 3.0.1
info:
  title: AU10TIX API
  description: >-
    AU10TIX exposes a REST API (the Back Office Server, "BOS") for identity
    verification, document authentication, biometric face comparison, liveness,
    and fraud detection, alongside web and mobile SDKs. A typical integration
    creates a verification workflow/session, uploads document and selfie media,
    then retrieves a structured result by session identifier (polling) or via
    asynchronous webhook callback.


    AU10TIX does not publish a public, openly accessible OpenAPI/Swagger
    definition or a public developer reference at the time of writing. The full
    API specification — exact request/response schemas, endpoint paths, and the
    OAuth2 token endpoint — is provided to onboarded customers and partners under
    account. Authentication is OAuth2 (bearer/JWT access token) for the current
    BOS REST API, and certificate-based (client certificate / mutual TLS) for
    legacy BOS integrations. Because no authoritative public path definitions are
    available, no paths are fabricated below; this document captures the verified
    metadata (servers, security, regional base URLs) only.


    Regional base URLs are documented for the legacy BOS endpoints, for example
    https://euxbos.cloudapp.net/Au10tixBos2/ (Europe) and
    https://usxbos.cloudapp.net/Au10tixBos2/ (USA). The current platform routes
    through regional service hosts such as https://eus-api.au10tixservices.com.
    Confirm the correct host and full paths with AU10TIX onboarding documentation
    for your account/region.
  termsOfService: https://www.au10tix.com/policies/
  contact:
    name: AU10TIX
    url: https://www.au10tix.com/company/contact-us/
  version: '1.0'
servers:
  - url: https://eus-api.au10tixservices.com
    description: AU10TIX regional service host (BOS REST API)
  - url: https://euxbos.cloudapp.net/Au10tixBos2
    description: Legacy BOS regional endpoint (Europe)
  - url: https://usxbos.cloudapp.net/Au10tixBos2
    description: Legacy BOS regional endpoint (USA)
security:
  - bearerAuth: []
  - clientCertificate: []
paths: {}
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: >-
        OAuth2 access token (JWT) presented as a Bearer token in the
        Authorization header on each request to the current BOS REST API.
    clientCertificate:
      type: apiKey
      in: header
      name: X-Client-Certificate
      description: >-
        Legacy BOS integrations are secured by certificate-based authentication
        (mutual TLS); AU10TIX issues a unique client certificate to each calling
        party. Represented here as a security scheme placeholder because mutual
        TLS is configured at the transport layer rather than in a request header.