Work · Community report

Build a custom transit connector

@sandeep.xr.ai.iot reports building and deploying a prototype TTC connector entirely in the Muse app, from API code and widget templates to GitHub, Railway and Cloudflare DNS, though the post shows no code or test results. This page plans a custom transit connector with review and approval at each step.

What you can get

What it is

Prototype connector service, skill text and widget template

A reviewed prototype plan and code for a custom transit connector, with deployment steps you approve one by one; not an official or supported integration.

It came back right when

Answers for stops you know match the agency's own site or app
No API key or token appears in the repository or its history
An empty or failed feed shows an error, not stale times

The checks are editorial, not from the source.

Illustration — suggested task flow, not an execution result

Prepare
The transit agency's public data feed or API, its terms and any API key
Ask and review
Pick the data source first: read the transit agency's developer page, note the feed format (for example GTFS or GTFS-realtime), any API key and the licence terms.
Check the result
Answers for stops you know match the agency's own site or app

The source case

@sandeep.xr.ai.iot reports building a prototype TTC (Toronto Transit Commission) custom connector for Meta Muse. By their account, they built and deployed it entirely in the Muse app: writing the API code, the connector skill and animated HTML widget templates, committing to GitHub, pushing to Railway, setting up DNS on Cloudflare and testing it end to end. The post shows no code, repository, connector address, test results or screenshots, and it does not say which TTC data source the connector uses or how much of each step the author did by hand. They call it a prototype, so it should not be read as a finished or supported integration.

— @sandeep.xr.ai.iot · Threads · Read the source · checked 2026-11-02

A public report by someone outside this library. Not independently reproduced here.

From the source

Source excerpt

I have built a prototype of a TTC (Toronto Transit Commission) Custom Connector for @Meta Muse 🚌. I built and deployed it entirely using the Muse app like writing the API code, the connector skill, animated HTML widget templates, committing to GitHub, pushing to Railway, setting up DNS on Cloudflare, and testing it end to end.

@sandeep.xr.ai.iot · Read it at the source · checked 2026-11-02

Quoted from the original posts. Not written by this guide, and not a result produced here.

Suggested prompt

I want to build a prototype custom connector for Muse that answers questions about [transit agency, e.g. TTC] using [the agency's public data feed or API: name and URL]. First read the agency's developer terms and tell me what data is available, any API key or rate limits, and whether the licence allows this use. Then write (1) a small API service in [language/framework] that fetches [arrivals / routes / service alerts] for a stop or route I name, (2) the connector skill description that tells Muse when and how to call it, and (3) an HTML widget template for showing the result. Show me the code and a list of every file before anything leaves this chat. Do not commit to [GitHub repo], deploy to [host, e.g. Railway] or change DNS on [DNS provider, e.g. Cloudflare] until I approve each step separately. Never put API keys in the repository; tell me which environment variables to set myself. Finish with an end-to-end test plan: three questions to ask, the expected answer and how to check it against the agency's own site.

Bring The transit agency's public data feed or API, its terms and any API key, A GitHub repository you control and a hosting account (the author used Railway), A domain and DNS access if you want a custom address (the author used Cloudflare), Stops or routes you can check by hand for the end-to-end test. Source community report, checked 2026-11-02.

Written by this guide as a starting point, not quoted from the source. Your edits stay in this browser.

What you need

You supply

The transit agency's public data feed or API, its terms and any API key
A GitHub repository you control and a hosting account (the author used Railway)
A domain and DNS access if you want a custom address (the author used Cloudflare)
Stops or routes you can check by hand for the end-to-end test

How to try it

Editorial, not from the source

Pick the data source first: read the transit agency's developer page, note the feed format (for example GTFS or GTFS-realtime), any API key and the licence terms.
Ask for a small API service that answers one narrow question, such as the next arrivals at a stop you name, and read the code before anything is committed.
Have the agent draft the connector skill text that says when Muse should call the service and what each field means; check it against the real responses.
Review the HTML widget template with a real response and an empty or error response, so a missing feed does not show stale times as live.
Approve the GitHub commit, the deploy to your host and any DNS record as three separate steps, and set API keys as environment variables yourself.
Test end to end with stops you know, comparing the connector's answers with the agency's own site or app, and keep the prototype label until those checks pass.

What the author says they built

@sandeep.xr.ai.iot describes a prototype connector for the Toronto Transit Commission, built for Meta Muse. The list of parts is specific: API code, a connector skill, animated HTML widget templates, a GitHub commit, a push to Railway, DNS on Cloudflare and an end-to-end test, all done, in their words, "entirely using the Muse app".

That is the whole account. The post does not link the repository or the live service, does not show what a rider would see, and does not say which transit data it reads, so the build and the test result remain the author's report.

Choosing a transit data source

In general, transit agencies publish schedules as GTFS files and live vehicle or arrival data through GTFS-realtime or their own APIs. Many require you to register for a key and accept terms that limit caching, branding or commercial use, so read those before any code is written.

Keep the first version narrow. One question answered well, such as the next few arrivals at a named stop, is easier to check than a connector that tries to cover routes, alerts and trip planning at once.

Deploying without surprises

Each outward step changes something real: a commit makes code public if the repository is public, a push to a host starts a running service that may cost money, and a DNS record points a domain at it. Approve them one at a time and read the diff or the record before you say yes.

Keep secrets out of the repository. Set the agency API key and any host tokens as environment variables in the hosting dashboard yourself, and check the commit history for keys before making the repository public.

Open Muse to try it. That is the product's own site; this guide is not part of it.

Limits and confirmation points

Limits to confirm

The post shows no code, repository, deployed address, logs or test results, so what "testing it end to end" covered is unknown.
It does not name the TTC data source, API keys or licence terms, or say which steps the author typed, approved or fixed by hand.
The author calls it a prototype; nothing in the post shows it is published to other users or reviewed by the transit agency or by Meta.
This is an attributed community report, not reproduced by this guide. The suggested workflow and checks are editorial guidance, not a recovered conversation or guaranteed product capability.

If it goes wrong

Editorial, not from the source

The connector returns arrival times that do not match the agency's app: Check whether the code reads the static schedule instead of the real-time feed, and compare the stop ID it uses with the agency's stop list.
The deploy works but the custom domain does not load: Confirm the DNS record the host asks for (often a CNAME) matches what was set at the DNS provider, and allow time for the change to take effect.
Muse does not call the connector when you ask a transit question: Reread the connector skill text: it should name the kinds of questions it answers and the inputs it needs, such as a stop name or route number.

Common questions

Can Muse build and deploy a custom connector?

One user reports building and deploying a TTC connector entirely in the Muse app, from API code to GitHub, Railway and Cloudflare DNS. The post shows no code or test output, and this guide has not reproduced it.

What data does a transit connector need?

A public schedule or real-time feed from the agency, usually GTFS or GTFS-realtime, plus any API key the agency requires. The source post does not say which TTC feed the author used.

Do I need my own hosting and domain?

In the author's account the service was pushed to Railway and DNS was set up on Cloudflare. A connector generally needs a reachable address, but which host or domain you use is your choice.

Is the TTC connector available to other Muse users?

The post calls it a prototype and does not say it was shared or published, so there is no evidence it is available to anyone else.

Related to this task

Review an agent connector setup A connector review and test log with a bounded installation decision, not an assurance of autonomous secure deployment.
Run a full coding workflow for you A coding task taken from branch to a pushed, verified change in an isolated VM, connected to your GitHub and hosting platform, with a result you can check from anywhere.

Similar tasks

Build and deploy a WordPress site Creative · A running WordPress site with a theme built for it, and the theme's code pushed to a GitHub repo you can review.
Build a small playable game Creative · A small game prototype and a recorded play-test checklist, not an unverified claim of a finished public game.

Get recurring task recommendations — ask your own agent to check for relevant updates.