Skip to main content

Ingenious API — Overview & Reference Guide

Taylor Vickhammer avatar
Written by Taylor Vickhammer
Updated this week

Overview

The Ingenious API gives teams a simple, secure way to connect external systems, automate key workflows, and build custom solutions on top of the Ingenious Platform. With clear documentation, predictable REST endpoints, and well-defined change management, developers can integrate with confidence and scale their solutions safely.
​

The API is designed for both lightweight internal scripts and full production-grade integrations.

What is Ingenious API?

The Ingenious API is a RESTful, Open API that provides secure, programmatic access to project, financial, and operational data within the Ingenious Platform.

Key characteristics include:

  • Predictable, resource-based REST endpoints

  • Standard HTTP methods: GET, POST, PUT, PATCH, DELETE

  • Structured JSON request and response payloads

  • Secure authentication using access tokens or OAuth 2.0

  • Versioning and deprecation processes to protect existing integrations

This makes it easy to integrate Ingenious with external systems, automate workflows, or build custom applications.

What Customers Use the API For

Customers commonly use the Ingenious API to:

  • Build custom integrations with internal or third-party systems

  • Programmatically import and export data instead of using the UI

  • Automate repeatable workflows that must run reliably over time

Because many integrations run automatically, backward compatibility and change management are critical.

Where to Find API Documentation

All official API reference materials are available at:

➡ https://api.ingenious.build/reference/getaccounttypepub

This documentation hub includes:

  • Endpoint definitions

  • Required and optional parameters

  • Authentication details

  • Request and response examples

  • Version-specific behavior

If you are building or troubleshooting an integration, this should always be your first stop.

Authentication Methods

Access Tokens (Simple Method)

  • Generated in Company Settings → Access Tokens

  • Long-lived tokens used for:

    • Troubleshooting

    • Simple internal scripts

Usage:

OAuth 2.0 (Client Credentials Flow)

  • Configured in Company Settings → OAuth Applications

  • Required for secure, production integrations

⚠️ Critical Warning

Never regenerate a client’s OAuth Client Secret. Doing so will immediately break all live integrations. Only the client may regenerate it and must accept the consequences.

OAuth 2.0 Setup in Postman

  1. Open the Authorization tab → Type: OAuth 2.0

  2. Configure Token:

    1. Token Name: any value

    2. Grant Type: Client Credentials

    3. Access Token URL: https://<WORKSPACE_SUBDOMAIN>.ingenious.build/api/v2/oauth/token

    4. Client ID: provided by the client

    1. Client Secret: provided by the client (do not regenerate)

    2. Scope: leave blank

    3. Client Authentication: Send as Basic Auth header

  3. Click Get New Access Token → Proceed → Use Token

  4. Ensure header prefix is Bearer

Notes:

  • OAuth tokens are valid for 24 hours

  • Re-generate tokens in Postman when expired

API Change Management

Non-Breaking Changes

Non-breaking changes are safe improvements that do not affect existing integrations.

Examples include:

  • Adding optional fields

  • Adding new filter options

  • Expanding enum values

  • Introducing new endpoints

Communication:

These changes are published in the Public Changelog and typically require no customer action.

Breaking Changes

Breaking changes require customers to modify their existing code.

Examples include:

  • Renaming or removing fields

  • Changing data types

  • Modifying endpoint paths or response structures

Engineering avoids breaking changes whenever possible.

Deprecation Process

When a breaking change is unavoidable, the following process is used:

  1. Documentation Marking
    ​    Affected fields or endpoints are marked as “will deprecate soon.”

  2. Public Changelog Announcement
    ​    The change and timeline are announced approximately 2–4 weeks in advance.

  3. Transition Period
    ​    The deprecated version remains available for a defined period.

  4. Final Removal
    ​    The old behavior is removed only after the transition period ends.

​Customer Communication Rules

  • All API change notices are published in the Public Changelog

  • Customers should subscribe to the Changelog to stay informed

  • Direct customer emails about API changes are not sent

If customers report unexpected behavior:

  • Check the Public Changelog first

  • Escalate unannounced breaking behavior as a bug

  • Encourage customers to follow the Changelog going forward

API Versioning

API versioning is used when breaking changes cannot be handled through deprecation alone.

  • New versions (for example, v2) contain the breaking changes

  • Older versions remain active temporarily to allow migration

When troubleshooting:

  • Identify which API version the customer is using

  • Reference the documentation for that specific version

  • Guide the customer through migration if needed

When to Contact Support

If you encounter issues not covered in the documentation or need assistance with troubleshooting unexpected behavior, our Support Team is here to help. However, reviewing the API reference before reaching out will often give you the answers you need immediately.

  • Token Name: any value

  • Grant Type: Client Credentials

  • Access Token URL:

  • Client ID: provided by the client

  • Client Secret: provided by the client (do not regenerate)

  • Scope: leave blank

  • Client Authentication: Send as Basic Auth headertely.

Did this answer your question?