Overview

For OAA payloads that exceed 100 MB after compression, you can use multipart upload to split the payload into smaller chunks and upload them sequentially. The Veza platform assembles the chunks server-side before processing.

Multipart upload is useful when:

• The payload is too large for a single HTTP request

• Network reliability is a concern for large transfers

• You need to monitor upload progress for very large data sources

1. Start the upload by sending a start request — the server creates an upload session and returns an upload_id.

2. Upload chunks sequentially, each base64-encoding a raw slice of the payload. Include the upload_id from step 1 and an incrementing sequence_number.

Each chunk must be base64-encoded from raw bytes before sending. The server decodes and reassembles chunks in sequence order when the complete operation is received.

The response returns an upload_id (UUID string) to use in all subsequent requests for this upload session.

Send a separate POST to the same endpoint after all chunks are uploaded:

The oaaclient Python SDK handles multipart upload automatically when enabled:

When enable_multipart is set to True, the SDK automatically switches to multipart for payloads exceeding 50 MB (uncompressed) and:

• Splits the payload into chunks and base64-encodes each one individually

• Starts an upload session and tracks the upload_id

• Uploads each chunk sequentially with the correct sequence_number

• All chunks for a given upload_id must be uploaded before sending the completion operation.

• You can re-upload a chunk with the same sequence_number and upload_id if needed — the last upload for a given sequence number is used. All chunks must be present before the completion operation is sent.

• Chunk order is determined by sequence_number

Veza can enrich custom application (OAA) users with SSO last login timestamps by correlating Okta sign-in activity with your application's local users. When enabled, each local user in the Veza graph gains a sso_last_login_at property showing the last time that user accessed the application through Okta SSO.

This is useful for identifying dormant accounts, auditing access patterns, and supporting access reviews.

How it works

1. You specify the Okta Application ID (okta_app_id) for your custom application.

2. For this enrichment, Veza matches your OAA local users to Okta users using the matching property you set with the Veza API in Step 2.

3. On each data push, Veza looks up Okta SSO activity for your application and writes the last login timestamp to matching local users.

Enrichment runs in the OAA service after data submission. If Okta activity data is unavailable, the push completes normally without SSO timestamps, and no data is lost.

Veza queries Okta activity at push time, stores the result with the submission, and replays that stored result on later parses without querying again. A sso_last_login_at value therefore reflects the most recent push of that application, not the most recent parse or Okta extraction.

After an Okta audit log extraction completes, push the application again to include the new activity. A scheduled parse of the application does not retrieve it, because the parse replays the stored result. For a CSV integration, upload the file again. A second extraction of the Okta integration is not required: the regular Okta extraction only places the Okta users in Access Graph so that they can be matched.

• An active Okta integration in Veza with . Audit log data is the source for sso_last_login_at timestamps.

• A custom application (OAA) integration, using either API push or CSV upload.

• The Okta App ID (okta_app_id) set on the application, described in Step 4.

Contact your Veza representative or support team and request:

Enable the INTEG_OAA_SSO_LAST_LOGIN feature flag on this tenant.

This flag is Veza-administered and cannot be self-enabled.

Configure which Okta user property Veza uses to correlate Okta users with your application's local users. You can set this yourself using the Veza API.

The string you pass as value specifies which OktaUser attribute to use for identity mapping. The attribute value on each Okta user must match the identities field on the linked OAA local users.

• For example, if local users have identities: ["jane.doe@company.com"] and OktaUser nodes have login: "jane.doe@company.com", use login.

• Custom attributes (e.g., customprop_employee_id) are also supported.

To set the property, send a PUT request with an API key that has the admin or system_monitoring role:

Replace <okta_user_property_name> with the OktaUser property to match on (e.g., login, email, or a custom attribute such as customprop_idx_uid).

To verify the current value:

Look for the okta_sso_user_matching_property key in the response.

Locate the Okta Application ID (0oa…) for the application you want to enrich:

1. Log in to your Okta Admin Console.

2. Navigate to Applications > Applications.

3. Select the application.

4. Copy the application ID from the URL (format: 0oaXXXXXXXXXXXXXXXX).

The method depends on how you push data to Veza.

Add the okta_app_id field to your application payload at the application level:

• okta_app_id (application level): Your Okta Application ID.

• identities (user level): One or more identity strings matched against the configured Okta user property.

1. Navigate to Integrations > Custom Application (CSV).

2. Enter your Okta Application ID in the Okta App ID field in the application configuration form.

3. Upload your CSV as usual, ensuring users have identity values that match their Okta profiles.

After pushing data, verify enrichment is working:

1. Open Query Builder in Veza.

2. Query for your custom application's local users.

3. Check the sso_last_login_at column on user nodes.

Users whose identities matched an Okta user with SSO activity for your application will have a sso_last_login_at timestamp. Users without a match (such as service accounts or users not in Okta) will not have this property — this is expected.

• Matching is case-insensitive. Jane.Doe@company.com and jane.doe@company.com are treated as the same identity.

• First match wins. If a user has multiple identities, the first one that matches an Okta user is used.

• Enrichment is non-blocking. If Okta data is unavailable, the push completes without SSO timestamps. No data is lost.

This document provides a basic overview of the API requests for creating and updating an OAA data source. These steps and API calls can be adapted for your client or programming language of choice. You can also use the oaaclient Python module to handle Veza authentication, register the data source, and push the populated template.

Overview

While registering sources and pushing authorization metadata with Open Authorization API is relatively straightforward, it is important to understand how Veza organizes custom providers and data sources as endpoints:

• You will first register a new custom application provider with a POST request to /api/providers/custom (specifying the app name and template).

  • The determines the type of entities the provider supports (application, identity_provider, or hris).

• Each custom provider can have one or more data sources (such as different instances or domains), generated using .

  • The populated template can describe additional resources and sub-resources, such as individual databases, repositories, or views.

• You can for each custom data source.

• All custom data sources are shown on the Configuration > Apps & Data Sources menu, and can be retrieved using .

You should typically name the provider based on the generic application provider (such as GitHub) and the data source after the top-level instance (such as GitHub - Organization). See the for more information about parsing and identifying entities using metadata from the source application.

Your requests will need to include a Veza API Key. For OAA APIs, using a is recommended. Provide it as the bearer auth token in the header of each request, for example:

Follow best practices for managing API keys: Do not save credentials in connector code. Consider using a secrets manager to securely store API keys and make them available at run time.

To add a custom application, you will need to:

• Create a new custom provider and data source.

• push the entity and authorization data in a JSON payload.

Use to register a new top-level custom provider. The custom_template determines what kind of entities you can push to the provider.

Custom Application provider

This is a common configuration with broad support for modeling applications with local identities, resources, and authorization:

Custom Application with SCIM lifecycle management

If your application exposes SCIM 2.0 endpoints, it can support automated provisioning and deprovisioning through :

Custom Application with REST lifecycle management

For applications that expose custom REST APIs (but not SCIM) for user provisioning. Veza sends REST requests to the application's endpoints through the Insight Point, which must have network access to the target application:

Custom Identity Provider

This template is for modeling custom or unsupported identity providers as a source of users and groups:

Identities and groups in the custom provider can mapped to local accounts in other systems, and assigned as entity owners. Custom IdPs can also be used a source of identity for Lifecycle Management policies.

HRIS Provider

This template is intended to model HR information systems. Set provisioning to true to use the HRIS as a system of record for Lifecycle Management policies:

Provider creation response

All provider creation requests return the Provider ID, which you will need to create and manage data sources:

Provider creation fields

Using the Python SDK

The oaaclient SDK provides create_provider() with an options parameter for advanced fields:

Each provider needs at least one data source. Create one with

The response will include the data source ID:

• Datasources should be unique to the data collected by an OAA integration instance. For example, if an application has a "prod" and "dev" instance, creating a datasource for each will enable independent updates to each environment.

• Name the data source uniquely based on the application instance to discover. Try to include the hostname or organization name in the data source. For example, don't use "GitHub" use "GitHub - Acme Inc" or "Portal - prod.corp.com"

• Note that a provider id is required in both the request path and body.

Once the data source and provider are active, publish the payload with . The request body must include the Provider ID and Data Source ID.

json_data must contain the populated OAA template as a single JSON string (escaping any unsafe characters such as ").

Specifying the Provider ID and Data Source ID, perform the same used for the initial push.

To update an existing data source, use the operations and operations to get the provider and data source IDs.

Use these REST API calls to manage and update custom providers and data sources with Open Authorization API.

Create Custom Provider

Creates a custom provider and returns the provider ID.

List Custom Providers

Lists all configured custom providers.

Get Custom Provider by ID

Returns details for an individual custom provider.

Delete Custom Provider

Delete a custom provider by ID.

List Custom Provider Datasources

Return all data sources for a Custom Provider ID.

You can constrain large responses by adding a filter to the request query string. Include the operator (eq), and value, for example:

CURL <VEZA_URL>/api/v1/providers/custom?filter=name eq "GitHub"&order_by=state

Create Custom Provider Datasource

Register a new datasource for a custom provider. There can be more than one datasource for a single provider.

Returns details for a single datasource.

Unbind a datasource from a custom provider, and delete it.

To push authorization metadata for a custom datasource, you can specify the source and provider IDs, and upload a payload with the entities and permissions in JSON format.

A warning is returned for any non-critical errors during payload processing. These can indicate incomplete or inaccurate data in the payload that do not prevent processing, but may warrant attention.

For large payloads that exceed 100 MB, use the multipart upload endpoint to upload the payload in chunks. See for details, examples, and Python SDK usage.

For , this endpoint pushes CSV data to an existing datasource. Typically, you will first create the integration and define column mappings using the "Add Integration" flow in Veza.

CSV data must base64 encoded into the JSON body of the request.

The populated template can be compressed and encoded, for significantly reduced payload size.

• Specify the compression_type. Currently supported: GZIP.

• If compression is selected, Veza will expect the payload json_data as a compressed, base64-encoded string.

To compress using shell commands:

Size is typically not an issue when updating custom datasources. However, you may want to compress large payloads. The maximum body size is 100MB (compressed or uncompressed).

Veza expects the populated template as a single JSON string, enclosed in the request body json_data field. Any "s and non-ASCII characters must be escaped.

To convert a template to JSON string using Python, the json.dumps() method could be used:

You can optionally add an icon for your custom provider by uploading a PNG or SVG file (less than 64kb) as a base64-encoded string:

Upload a custom icon to display for an OAA provider.

Return the type and string-encoded icon for a custom provider.

Delete the icon associated with an OAA provider.