Platform API
Your App Asked a Model.
What Happened Next?
A customer starts an AI task. It calls tools, hits a failure and returns an answer. You need something more useful than a screenshot of the chat.
“Keep the run identity. Show the tool result and the unresolved effect.”
Build the feature. Keep a way to investigate it.
The platform API gives your application a structured place for runs, tools and evidence. Your application still owns its interface, credentials and verification of its own reported effects.
Try The Situation
Interactive simulation. Fixed sample data. No real actions.
Back In Your Own Work
What Changes
When You Use This?
- One integration path through the published platform contracts.
- Official Python and TypeScript clients with examples.
- A way to relate application-reported activity to an inspectable run record.
Before you try it for real.
The example explains the behavior. Your actual tools, account and evidence determine what is possible.
What You Need
A Dyadic account and scoped API key. Provider availability, account limits and paid usage still apply.
What Is Enforced, Recorded Or Advised
The API owns authorization, usage and lifecycle rules. Client code can request a scope but cannot grant itself a broader one.
Where It Stops
Compatibility covers the published subset, not every upstream feature. An application's own reported outcome is not an independent observation. Review API limits and configure recording deliberately.
The Workflow, Step By Step
Choose The Contract
Use the platform API for Dyadic agent capabilities, or the documented OpenAI/Anthropic-compatible subset for supported client workflows.
Scope The Integration
Give the application its own key and configure the tools, permissions and workspace it needs. Keep credentials server-side.
Inspect The Run
Use structured responses, streaming and the available run evidence. Verify side effects in your application rather than trusting a generated success sentence.
Bring Your Own Version Of This Problem.