Public API Integration

​

Implementation Overview

Implementation Type: Minimal Implementation (Webhook-based)
Note Format: N/A
Status: Production Ready The Public API integration is not a traditional ATS integration. Instead, it provides a minimal ATS client implementation that supports webhook-based integrations for organizations using Tenzo’s Public API rather than a traditional ATS system.

​

Configuration

​

Feature Coverage

​

Implementation Notes

​

Webhook-Based Architecture

The Public API integration works differently from traditional ATS integrations:

1. Inbound: Organizations push job and candidate data to Tenzo via Public API
2. Processing: Tenzo processes interviews and generates results
3. Outbound: Results are sent back via configured webhooks

​

Temporary Storage

The client uses temporary storage fields:

• _temp_candidate: Stores candidate data during processing
• _temp_resume: Stores resume data during processing

​

Post-Call Results

Override of post_call_results() method sends interview results via webhook instead of writing back to an ATS.

​

Job Cache Usage

Jobs created via Public API are stored in AtsJobCache and retrieved from there rather than from an external system.

​

Webhook Integration

The Public API client integrates with the webhook service (webhook_service.py) to:

• Send interview results to customer endpoints
• Notify customers of processing completion
• Deliver structured interview data

​

Known Limitations

​

Use Cases

The Public API integration is appropriate for:

• Organizations without a traditional ATS
• Custom-built applicant management systems
• Integration with internal HR systems
• Webhook-based workflows

​

Meeting Copilot Endpoints

The Public API exposes a set of Meeting Copilot resources. The read-only getters — list_meeting_copilot_notes, get_meeting_copilot_note, list_meeting_copilot_templates, and get_meeting_copilot_template — are also surfaced as MCP tools and documented under the Meeting Copilot tag in the Tenzo Public API reference.

​

Create a Meeting Copilot note

Endpoint: POST /api/v1/meeting-copilot-note Hand a finished transcript to Tenzo and have it build a Meeting Copilot note, optionally running the same post-meeting pipeline the in-app bot uses when a meeting ends. Because this is a write operation, it is not exposed as an MCP tool (unlike the read-only Meeting Copilot getters) — call the REST API directly. The customer-facing contract (request body, transcript limits, response, errors, and a worked example) lives in the Meeting Copilot guide. The generated Tenzo Public API reference covers the same routes under the Meeting Copilot tag. Keep the field tables in the guide only — don’t re-add them here. Internal notes:

• Access is gated on the MEETING_NOTES_ACCESS flag via require_notes_access; orgs without it get a 403 on every call regardless of key validity.
• Transcript caps are enforced in CreateMeetingCopilotNoteRequest (5000 lines, 20,000 chars/line, 800,000 total UTF-8 bytes) to keep the note under the Cosmos ~2MB item limit. The byte cap is a Pydantic model_validator, so it is not expressible in the generated JSON Schema — the guide states it in prose instead.
• If save_transcript fails the just-created note is deleted and the caller gets a 503, so a retry starts clean.
• The optional per-note config fields (ats_writes — a single flag mapped to both internal toggles update_ats_job and write_candidate_fields_to_ats — plus intake_field_overrides, remote_ats_job_id, description_draft, company_remote_id, contact_remote_id) mirror the note’s in-app Config panel. All but intake_field_overrides are create_note parameters; the overrides are applied via save_note (the same partial-update path the config WebSocket uses) before the transcript is saved and the pipeline scheduled. None/omitted means “inherit the template default”.
• company_remote_id and contact_remote_id are intake-only. When provided, the controller queries the org’s ATS client (get_job_creation_entity_ref) to resolve human-readable labels (e.g. Bullhorn ClientCorporation and ClientContact) and populates job_creation_params.entity_refs, unlocking the ATS Sync entity pickers.
• An optional Idempotency-Key HTTP header caches successful responses in Redis for 24 hours (public_api:meeting_note:idempotency:{org_id}:{key}), returning identical cached responses on network retries without creating duplicate notes.
• A tag only renders in the published ReDoc reference if it appears in both spec["tags"] and x-tagGroups in build_public_openapi(). Adding a route with a brand-new tag without updating both silently omits it from the docs — find_unrendered_route_tags() catches this in a unit test (routes marked include_in_schema=False, like the MCP-only read-only getters, are intentionally excluded).

​

Related Files

• Implementation: server/ats/public_api/public_api_ats_client.py
• Webhook Service: server/ats/public_api/webhook_service.py
• Public API Endpoints: server/ats/public_api/public_api.py
• Application Controller: server/ats/public_api/public_application_controller.py
• Job Controller: server/ats/public_api/public_job_controller.py
• Meeting Copilot Note Controller: server/ats/public_api/public_meeting_note_controller.py
• README: server/ats/public_api/README.md

​

See Also

• ATS Coverage Matrix
• Public API Reference (Redoc)