Create Data as API

Securely share your data with external entities or integrate their data into third-party applications.

Data as API

Data as API lets you expose a Data Set as a secure, reusable REST service so external systems (or other BDB modules) can consume your curated data without caring about storage or implementation details.

Prerequisites:

• You have a Data Set created and (ideally) validated.

• You have permission to create Data as API services.

• (Recommended) Know the parameters you want to expose and any record limits.

Publish Data as an API

Navigation: Data Center → New → Data As API

1. Open the wizard

   • Navigate to the Data Center homepage.

   • Click New → select Data As API. Result: The Data as API page opens, listing available Data Sets.

2. Choose a Data Set

   • Select a Data Set from the list.

   • Click Publish As Data Service (icon).

3. Fill in the Publish As Data Service form

   • Service Name: A unique name for this API service.

   • Category: Select an existing category or create a new one (helps organize APIs).

   • Description: Briefly describe the service/use case.

   • Parameters: Define input parameters your API will accept (e.g., fromDate, region).

   • Limit: Maximum number of records the API should return per request.

   • (Optional) Filters: Add filter(s) to restrict rows served by the API.

   • Click Save.

4. Confirm

   • A confirmation message appears.

   • The newly published service is listed in the Data as API list (newest on top).

Note: The Data Set you published also appears in the API Client Registration form’s drop-down (use this to register a client and obtain access credentials).

After Publishing

• Your service is visible under Data as API with action icons (see Manage an API Service below).

• To consume the API externally, register a new client (Client ID/secret or equivalent) and use the issued credentials.

• Inside the platform, you can ingest your API via the Data Pipeline → API Ingestion component.

Manage an API Service (Actions)

Name	Action
Message Configuration	Define the message returned when the API yields no data.
Push to VCS	Push the current API definition to Git with a commit message (versioning & rollback).
Pull from VCS	Restore a prior API definition/version from Git.
Edit	Reopen Publish As Data Service to modify Service Name/Category/Description/Parameters/Limit/Filters.
Delete	Remove the API service from the list.

Notes:

• Version control (Push/Pull) affects the API definition, not the underlying Data Set version. Manage Data Set versions separately if required.

• Filters & Parameters: Use these to enforce governance and reduce payload size. Parameters are exposed as API query inputs; filters constrain data server-side.

• Client registration required: Consumers must register to access the API. Ensure appropriate scopes/permissions are applied.

• Pipelines: Once exported, the service can be read by the API Ingestion component for downstream processing.

Best Practices

• Name & categorize clearly (e.g., sales-orders-read, Category: SalesOps).

• Limit & paginate where appropriate to protect performance.

• Document parameters and default values in the Description for quick adoption.

• Use VCS after meaningful changes; include actionable commit messages.

• Add a no-data message to improve client UX.

Troubleshooting

• Service not listed after save: Refresh the Data as API list; verify you have publish rights.

• Client cannot access: Ensure the client is registered and mapped; check credentials/scopes.

• Empty responses: Review Filters/Parameters and Limit; validate the backing Data Set query.

• Wrong version: Use Pull from VCS to revert, then Save and retest.