Request a Source
Last updated March 21, 2026
Ask us to add a new public source to SynthLink. Share the source, what should be collected, and why it matters. We review every request against a small set of criteria and follow up if we need more detail.
What to include
A request does not need to include implementation details. What matters most is the source itself, the kind of information you want from it, and why it is useful. A good request should answer a few practical questions.
- What is the source?
- Is it publicly accessible?
- What kind of content should be collected?
- Why is this source valuable?
- How often does the source update?
- Are there a few example URLs or records we can inspect?
The more concrete the request, the faster we can evaluate it. The best requests describe the source in terms of documents, records, or events that should appear in SynthLink — rather than describing a crawler implementation.
Good request examples
Good requests usually include the following.
Source name and homepage
A direct link to the source, not just the organization's main page.
Example pages or feeds
2–3 representative URLs or sample records we can inspect.
Type of content to collect
Describe what a single record looks like — a post, a paper, a release note, a CVE.
Expected update interval
How often new records appear — hourly, daily, weekly.
Why the source matters
What problem it solves or what workflow it supports.
Known constraints
Rate limits, access restrictions, inconsistent formatting, or anything else we should know.
How we evaluate requests
When we receive a source request, we review it against a small set of criteria. Not every source is a good fit — some are too unstable, too sparse, too restricted, or too difficult to normalize into a reliable public dataset.
What happens after you submit
Source requests typically move through these stages.
Intake
We review the request for clarity and confirm what should actually be collected.
Feasibility review
We inspect the source, its structure, update behavior, and access constraints.
Scope definition
We decide what counts as a record, which fields should be captured, and how the source should appear in SynthLink.
Trial ingestion
We test whether the source can be collected consistently and whether the resulting records meet our quality bar.
Launch decision
If the source performs well, we schedule it for rollout and add it to the supported source set.
Expectations
Submitting a request does not guarantee that a source will be added. Approval depends on fit, quality, operational cost, and long-term maintainability.
If a request is a strong fit, we may follow up to clarify which subset of the source matters most, whether all records should be included or only a filtered slice, and what useful output looks like for your use case.
If a request is not a fit, we may decline it or defer it until the source becomes easier to support.
Note:Tips for faster review — link the exact source, include 2–3 representative examples, explain what should be collected and what can be ignored, tell us how you plan to use the data, and mention whether freshness matters.