AI Gateway API Documentation (14.0.12)

The AI Gateway API provides document processing capabilities for partner lending applications. It accepts document uploads, processes them through AI-powered analysis, and returns structured data extracted from documents.

• Batch document processing with concurrent handling
• Document type mapping: Bank Statement, Payslip, Electric Utility Bills, Tax Forms, Employment Certificates, etc.
• OCR data extraction with computed financial metrics
• Fraud detection and quality assessment scoring
• Asynchronous callback notifications
• Comprehensive error handling and validation

The API processes multiple document categories with customizable extraction schemas. Extracted fields can be extended beyond the standard set through fine-tuning to meet specific partner requirements.

Endpoint URLs are shared with partners individually.

Contact Boost Capital to receive environment-specific endpoint URLs and IP addresses for network configuration.

IP Addresses

The API operates from dedicated IP ranges:

• Ingress IP: Load balancer address for incoming API requests
• Egress IPs: Cloud Function addresses for outgoing callbacks

Specific IP addresses are provided during integration setup for firewall whitelisting.

The security measures described below represent the baseline configuration. These are not limited and can be extended, modified, or customized individually with partners based on specific security requirements and compliance obligations.

Partners have complete flexibility to choose which authentication and encryption methods to implement.

Mutual TLS (mTLS) provides bidirectional authentication for API domains. This setup ensures both the server and client verify each other's identity before any data is exchanged.

Requirements

For successful connection and client authentication:

• Client Certificate: client.cert file
• Client Private Key: client.key file

These cryptographic materials are securely shared by Boost Capital. The mTLS policy is configured to reject connections from clients that do not present a valid, trusted certificate.

Implementation

1. Obtain client.cert and client.key files from Boost Capital via secure channel
2. Configure HTTPS client to present client certificate during TLS handshake
3. Server validates client certificate against trusted certificate authority
4. Secure encrypted communication channel established

End-to-end encryption of all API request and response payloads provides an additional layer of data security.

Encryption Specifications

• Algorithm: AES-256-CBC with PKCS#7 padding
• Key/IV Management: Encryption keys and Initialization Vectors (IVs) are securely shared by Boost Capital
• Format: Base64-encoded encrypted JSON payload
• Content-Type: text/plain (when encryption is enabled)

Implementation Steps

Request Encryption:

1. Obtain the shared secret key and IV from Boost Capital via secure channel
2. Construct JSON request payload
3. Encrypt the JSON payload using AES-256-CBC with the provided key and IV
4. Base64-encode the encrypted data
5. Send the base64-encoded string as HTTP POST body with Content-Type: text/plain header

Response Decryption:

1. Receive response body as base64-encoded string
2. Base64-decode the response
3. Decrypt using AES-256-CBC with the same key and IV
4. Parse the decrypted JSON payload

Important: The request and response examples in this documentation display decrypted JSON for readability. In actual implementation with encryption enabled, payloads must be encrypted and base64-encoded as described above.

The API supports OAuth 2.0 authentication via Google Cloud Identity-Aware Proxy (IAP). This standard ensures only trusted service accounts can obtain access tokens required for API requests.

Requirements

Boost Capital will securely share:

• Service Account JSON file (e.g., service-account.json)
• IAP Audience (OAuth 2.0 Client ID)

Implementation Steps

1. Obtain Credentials: Receive service account JSON and IAP Audience from Boost Capital
2. Generate ID Token: Use the service account credentials and IAP Audience to obtain a Google-signed ID token
3. Authenticate Requests: Include the ID token in the Authorization header of every API request:

   Authorization: Bearer {idToken}
   

Token Management

• ID tokens have limited validity periods and must be refreshed periodically
• Implement token caching and automatic refresh logic
• Handle 401 Unauthorized responses by obtaining a new token

Sliding-window rate limiting is applied per tenant. The following limits are enforced:

File Processing Limits

When a rate limit is exceeded, the API responds with HTTP 429 and the following headers:

• Retry-After: seconds until the next request window opens
• X-RateLimit-Limit: configured request ceiling per window
• X-RateLimit-Remaining: requests remaining in the current window
• X-RateLimit-Reset: seconds until the current window resets

Recommended retry guidance: respect the Retry-After header; use exponential backoff (1s → 2s → 4s); maximum 3 retries.

{ "detail": "Error message describing what went wrong" }

Validation errors follow the Pydantic error format:

{
  "detail": [
    {
      "type": "error_type",
      "loc": ["body", "field_path"],
      "msg": "Human-readable error message",
      "ctx": {}
    }
  ]
}

• Retry on 500 errors with exponential backoff: 1s, 2s, 4s
• Do not retry on 422 validation errors
• Maximum recommended retries: 3 attempts
• Respect the Retry-After header on 429 responses

Use a unique submissionId for each application submission. Duplicate submissions with the same submissionId may be rejected or return the existing result.

For production integrations, implement a Dead Letter Queue (DLQ) or equivalent mechanism to hold unfulfilled requests temporarily when persistent 500 errors occur. This allows processing to resume once the API recovers, preventing data loss without re-ingesting original documents.

API endpoints for document processing and verification. The request body structures and examples shown in this documentation are displayed in decrypted JSON format for readability and ease of implementation. However, when payload encryption is enabled (see Payload Encryption section above), the actual HTTP POST body for all endpoints must be the base64-encoded, AES-256-CBC encrypted plain text string with the Content-Type:text/plain header. The same applies to response bodies - they will be returned as base64-encoded encrypted strings that must be decoded and decrypted using the same key and IV. Partners who choose not to implement payload encryption can send and receive standard JSON payloads with Content-Type:application/json.