Feedyou

Conversational AI — chatbots, voicebots and emailbots — from Feedyou.

This piece talks to the Feedyou Bot Management API v1.2.4. The authoritative spec is the OpenAPI document at https://api.swaggerhub.com/apis/feedyou/bot-management/1.2.4; the prose docs at https://docs.feedyou.ai/books/api-english-version cover a subset of it (the Export API and Trigger API pages).

There is no global base URL. Every Feedyou bot runs on its own Azure Function App, so the API lives at https://feedbot-{BotId}.azurewebsites.net/api/management. Requests are authenticated with the bot's Azure Function key, sent as an x-functions-key header.

• Actions: Export User Data, Export Users By Date, Export AI Queries, Get User Transcript, List Campaigns, Add Contact To Campaign, Get Campaign Contact, Start Campaign, Pause Campaign, Cancel Campaign Contact, Get Repository Items, Create Repository Item, Update Repository Item, Update Repository Custom Fields, Bulk Replace Repository Items, Delete Repository Item.
• Triggers: New User Data (polling), New AI Query (polling).

Connection

The connection needs two values:

• Bot ID — the {BotId} in your bot's feedbot-{BotId}.azurewebsites.net domain. Pasting the whole domain (or the feedbot-… app name) works too; the piece normalises all three.
• API Key — the Azure Function key issued for that bot.

Ask your Feedyou implementation contact — or email [email protected] — for both. Feedyou does not currently expose them in a self-service settings page: bots are hosted on per-customer Azure Function Apps and the key is issued during onboarding. There is no published Designer menu path for finding either value, so this piece does not pretend there is one.

The connection is validated with a single GET /api/management/dialer/campaigns — the cheapest authenticated call in the spec, and one that does not touch the export tables Feedyou warns can be expensive.

Notes

• Filter your exports by date. Feedyou's own docs warn that calling GET /export/userData without timestamp filters "can return very large amount of data and affect bot performance". Set From / To on Export User Data, and prefer a narrow range on the date-scoped exports. The New User Data trigger always sends a fromTimestamp, and clamps its first poll (and every trigger test) to the last 24 hours for the same reason.
• Two different time formats, on purpose. GET /export/userData filters on second-based UNIX timestamps and returns timestamp as UNIX seconds. The date-scoped exports (/export/date/{date}/…, /export/from-date/{from}/to-date/{to}/…) take ISO dates in the path and return timestamp as an ISO 8601 string. The piece converts from the builder's date pickers in both directions; the raw values are passed through to the step output unchanged.
• Two different envelopes, also on purpose. GET /export/userData answers with a bare JSON array. The date-scoped exports wrap the same kind of rows in { "items": [ … ] }. Both are normalised to a users / queries array plus a count on the step output.
• Get User Transcript returns PascalCase keys. /transcript/users/{userId} is an Azure Table passthrough, so its rows use PartitionKey, RowKey, Timestamp, ConversationId, DialogId, StepId, StepType, Direction, Text — while every other endpoint in the API is camelCase. The rows are returned exactly as Feedyou sends them rather than silently renamed, so reference them as Text and Direction in downstream steps.
• Dynamic where filters. Export User Data's Field Equals input maps each key to a where{FieldName} query parameter, upper-casing the first letter for you — entering gender = male sends whereGender=male.
• Campaign.id is the campaign name. Every dialer path is keyed by name, and the id field the campaign list returns is that name. The Campaign dropdown on the dialer actions is backed by GET /dialer/campaigns.
• Start / Pause / Cancel return no body. Feedyou documents a bare 200 for /dialer/campaigns/{name}/start, /pause and /contacts/{id}/cancel, so those actions synthesise { success: true, … } rather than returning an empty object.
• POST /repository/{source} is create-only, not an upsert — the spec says it answers 409 when an item with the same id already exists. That is why the action is named Create Repository Item, with Update Repository Item (PATCH) alongside it.
• customFields semantics differ between the two update actions. PATCH /repository/{source}/{itemId} replaces the whole customFields object, whereas PATCH /repository/{source}/{itemId}/custom-fields merges only the keys you name. Use Update Repository Custom Fields to change one key without touching the others. Both actions omit fields you leave blank so a partial update never blanks a value you did not set.
• Bulk Replace deletes. PUT /repository/{source} upserts the array you send and then removes every item in that source that is not in it — an empty array clears the source. The action refuses an empty list unless Allow Clearing The Source is turned on, so an upstream step that produced nothing cannot silently wipe a catalogue.
• Polling triggers, because Feedyou has no webhook API. There is no subscription endpoint anywhere in the spec. The single push mechanism is the per-contact notificationUrl on a dialer contact, which is set when the contact is created and cannot be registered bot-wide. Both triggers therefore poll.
• Wiring up call-completion callbacks. Add Contact To Campaign exposes notificationUrl — paste a TaskMagic Catch Hook URL there and Feedyou will POST to it every time a call or call attempt for that contact ends. The payload is the spec's Notification schema: the Call object (callId, type, startTimestamp, endTimestamp, answered, hangupStatus — one of NORMAL / BUSY / REJECTED / INCORRECT / TEMP_UNAVAIL / CONGESTION / UNKNOWN — dialCount, dialsLeft, answeredDuration, duration, campaignName, contactId, outputs) plus state (PENDING / CANCELLED / FINISHED / FAILED / RETRY) and inputs. Feedyou does not document a signature or shared secret on this callback, so treat the payload as unauthenticated and confirm anything important with Get Campaign Contact.
• Trigger dedupe. New User Data dedupes on userId + timestamp; New AI Query dedupes on queryId, falling back to rowKey. New AI Query polls a date range that starts one day before the cursor, because the export partitions by UTC day and a poll just after midnight still needs the previous partition.
• Errors are inconsistent, and are parsed defensively. Only the /repository/* family documents an error body ({ "success": false, "error": "…" }, used for 400/404/409/500). The dialer endpoints document a bare 404 Campaign not found with no schema, and the export endpoints document no error responses at all. Auth failures come from the Azure Functions host rather than the bot, so a bad key returns a bare 401 with a plain-text body. Nothing here assumes JSON on a non-2xx: the piece tries JSON, then falls back to the raw text (truncated). The API key is never included in any error message.
• Rate limits are not documented. The spec publishes no limits, no headers and no 429 responses. The only guidance Feedyou gives is the soft warning above — filter by timestamp and fetch a day at a time rather than pulling everything. Every request carries a 30 second timeout.

Deliberately not shipped

• GET/POST /tree, GET /telephony/calls, GET /telephony/calls/{callId}/rec-file, GET /telephony/calls/{callId}/part-rec-file/{partUid}, GET /telephony/calls/{callId}/logs, and the /nlp/log/utteranceReport family (archive, archiveAll, unarchive, delete) — all documented as 200 with no response schema. Shipping an action whose output shape is a guess would be worse than not shipping it; these can be added once a live response is captured.
• The Trigger Dialog endpoint (POST /trigger/{addressBase64}/{dialogId}/{mode?}) — it is not in the OpenAPI spec at all, only on a prose docs page. Its response shape is defined by each customer in their own Designer rather than by the API, and the docs' example path (/api/trigger/…) contradicts its own prose (/api/management/trigger/…). It is omitted pending a live test rather than guessed at.
• Left out of v1 for scope, not for lack of documentation — these are fully schema'd and would be easy to add later: the remaining export tables (/export/userDataSnapshot, /export/nlpLog, /export/outgoingEmail, /export/outgoingSms, /export/fuzzyQuestionAnswerLog, /export/integrationLog, /export/urlTracker, and the date-scoped /export/…/nlp-log, all of which take the same fromTimestamp / toTimestamp pair), GET /dialer/campaigns/{campaignName}/contacts (list every contact in a campaign), GET /repository/{source}/{itemId}, PUT /repository/{source}/{itemId} (full replace — the destructive sibling of Update Repository Item) and POST /repository/import.
• GET /transcript/users (the list of users who have a transcript) and the /transcript/validator* endpoints have no response schema either, so Get User Transcript has to be given a userId from an export step or a trigger. Note that Get User Transcript itself is built against the spec's worked example rather than a formal schema — that example is complete and is where the PascalCase warning above comes from, but the field list is not guaranteed by a schema.
• No custom API call action. A passthrough would hand this connection's Function key to any URL a flow supplies.