# Limits that are not bugs > Behaviour that looks broken, is not, and will not be fixed — because the Chatfuel API cannot answer the question underneath it. Page: https://sdk.chatfuel.com/docs/troubleshooting/limits Markdown: https://sdk.chatfuel.com/docs/troubleshooting/limits.md None of these is a defect in the app the wizard writes. Each is a question the Chatfuel API does not answer, surfacing where you would expect an answer. They're here so you can recognise one in the first minute instead of the second hour — and so you don't file a bug that nobody can fix. ## A contact created seconds ago may not appear in a filtered list [#a-contact-created-seconds-ago-may-not-appear-in-a-filtered-list] Two engines answer contact queries and they see different things. The segment engine (`contactsConnection`) sees every contact and takes arbitrary attribute filters. The chats engine (`contactChatsConnection`) is live and searches server-side, but it lists only contacts that have a conversation — a contact created through the API, or imported from a CSV, comes back with no conversation and never appears there. On one live bot the two counts were 67 and 44: the missing 23 were exactly the contacts that had never messaged. The list says which engine answered. Ask for something only the chats engine can answer — unread, owner, stage, a last-message window — and you're on the engine that hides them. This one is silent by construction. The chats engine returns a clean, fast, empty result for a contact that exists and is sitting on the first page of the other engine. See [the Contacts module](/docs/modules/contacts). ## A filtered contact list does not update itself [#a-filtered-contact-list-does-not-update-itself] No subscription exists for the segment engine's shape, so under a filter the list is a snapshot and Refresh is the only thing that moves it. Live updates are the chats engine's, and that engine is the one that cannot express the filter. Under the chats engine, channel, sort and attribute predicates are applied to the rows that happened to load, client-side — so a count you read off a filtered chats-engine list is a count of what's loaded, not of what matches. ## Deals segments cannot be narrowed by stage [#deals-segments-cannot-be-narrowed-by-stage] `SegmentInput` has no sales-stage predicate. A segment export therefore covers the segment — every contact on the bot that matches it — not the column you were looking at when you started it. The export dialog says so rather than letting the pipeline filters on screen imply otherwise. The other export start takes contact ids, and that one does mean "these deals" — but it can only carry the rows that are loaded. Loading the rest of a column is what makes an export of it complete. See [the Deals module](/docs/modules/deals). ## The deals board filters by assignee and nothing else [#the-deals-board-filters-by-assignee-and-nothing-else] The board is one query per column — the column itself is the stage argument — and the only other filter that query takes is assignee. Stage subsets, unread, text search and attribute predicates belong to the other two engines, and those cannot isolate deals the way the board does. A filter bar offering them here would be a control that silently does nothing, so the board doesn't offer them. ## Publishing schedules need a database [#publishing-schedules-need-a-database] The Chatfuel API publishes immediately. No input takes a time, there is no draft entity, and the one `scheduledPublishTime` in the schema is read-only. A content calendar is not a view over something the platform holds — it's a view over a queue your deployment holds, so your deployment has to hold one. Without a database the module still composes and publishes on the spot, and it saves drafts to per-user storage. What it cannot offer is the queue and the calendar: a queue that only fires while somebody has a tab open is a reminder, and calling it a schedule is a lie a customer discovers at midnight. With a database — a table, a timer, and a route that publishes — the module offers the whole thing. [Scheduled publishing](/docs/guides/scheduled-publishing) is that setup. ## The media library only knows what this app published [#the-media-library-only-knows-what-this-app-published] None of the four Instagram media types carries a timestamp. The library can be ordered — the connection is newest-first — but it cannot be dated, so "posted last Tuesday" is not a question this API answers. Media can only be placed on a calendar when the app itself recorded when it went out, which means the calendar is a calendar of your own queue and the library is a separate, undated surface. The library also serves what the platform has already pulled down. Media created on the Instagram side isn't in it until a refetch runs — on a live account a list has been seen to go from three items to nine on the first one. See [the Publishing module](/docs/modules/publishing). ## Re-granting the Meta conversions permission has to happen in Chatfuel [#re-granting-the-meta-conversions-permission-has-to-happen-in-chatfuel] Conversions go out only while the bot's WhatsApp number carries the Meta conversions permission. When it doesn't, everything you configure is stored and nothing is delivered. Re-granting is an interactive consent; an app on the public API cannot give it on somebody's behalf, so the module reads the flag, says so, and links out to Chatfuel. The ads half is the same shape from the other side: listing the ads in a set needs a Facebook account with `ads_read`, and granting that is an interactive Facebook consent. See [the Ads Optimization module](/docs/modules/ads-optimization). ## Nothing reports what Meta did with a conversion [#nothing-reports-what-meta-did-with-a-conversion] Conversions are sent and forgotten. No query reports what Meta received, what it accepted, or how an ad performed afterwards. The ad insights that do exist carry no date range — one aggregate figure per ad, no frequency, no cost-per-anything, no conversions — so no trend can be drawn from them. Any interface claiming otherwise on this API invented it. ## The knowledge base has no size until a write is refused [#the-knowledge-base-has-no-size-until-a-write-is-refused] Everything in the record is fed to the assistant as text, so the server counts characters and refuses writes past a limit. There is no limit field in the schema: you can read what's spent (`usage.total`, and the catalog's share of it) and what each source spends, but not what the ceiling is. "Full" arrives as a verdict on a failed write, not as a number you can show in advance. That's why the module shows the composition rather than a gauge — a gauge would need a maximum, and inventing one would be inventing the fact. See [the Knowledge Base module](/docs/modules/knowledge-base). ## Bookings are the bot's clock, not yours [#bookings-are-the-bots-clock-not-yours] A time sent with a zero offset is read by the API as the bot's wall clock, not as UTC. Specialist schedules and availability are wall clock in the bot's zone too, and availability subtracts bookings by the wall clock of the stored string. The one framing under which storage, availability and the schedules all agree is the bot's own zone, so that's what the module renders in by default — your own zone is a per-user preference, offered when the two disagree. ## Two appointment reminders, and no others [#two-appointment-reminders-and-no-others] The booking configuration carries a confirmation message, a 24-hour notice and a 2-hour notice. Those two notices are the only reminders the API has. A different interval, a follow-up after the appointment, or a second reminder on the same booking is not something to configure — it isn't there. See [the Bookings module](/docs/modules/bookings). ## Something else looks wrong [#something-else-looks-wrong] If a symptom isn't here and isn't on the [symptom list](/docs/troubleshooting), it may be a bug. [Getting help](/docs/troubleshooting/support) has where to report it and what to include.