feat: integration development skill - #84
Conversation
protoss70
added
the
t-integrations
@protoss70, please use the correct keyword for connection PR otherwise it will not connect, see https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword |
drobnikj
left a comment
drobnikj
left a comment
There was a problem hiding this comment.
Looks good! Just a few notes.
JanHranicky
left a comment
JanHranicky
left a comment
There was a problem hiding this comment.
LGTM, nothing blocking. Pre-approving :)
|
|
||
| ## 13. Convenience operations: "Scrape single URL" | ||
|
|
||
| Beyond generic "run Actor", ship a curated **Scrape single URL** action: a 2-field form (`url`, `outputFormat`) wrapping a content scraper with sensible defaults (`maxCrawlDepth: 0`, `maxResults: 1`). Validate the URL first (`new URL()` + protocol + hostname check) with an actionable error - bad input must never start a paid run. Return a **lean, single-object** output: `{ ...pageMetadata, [outputFormat]: content }` - strip all content variants and re-add only the chosen one. This is ideal for LLM flows (a single object beats a dataset array) and lowers the barrier for non-power users. Point power users to the underlying Actor for advanced options. |
There was a problem hiding this comment.
We use WCC for scrape single url triggers, but we want to migrate towards unblocking teams Web fetch actor - https://apify.com/apify/web-fetch
I would make the skill follow this new convention. Call the Action Web fetch and use the correct Actor
There was a problem hiding this comment.
Created a follow up ticket for this since I am not quite sure on how the migration will look like now. Once I solve the Zapier migration to new fetch standby Actor I will update this
|
|
||
| ## 8. SDK handling and attribution | ||
|
|
||
| Use the official `apify-client` SDK (JS or Python), not raw HTTP. Construct the client once, memoized, and rebuilt only when the token changes. Stamp the attribution header on every request: `x-apify-integration-platform: <your-harness>`. When the request is driven by the AI tool (always, in this shape), also send `x-apify-integration-ai-tool: true`. This is the single most important line for Apify's side of the relationship. |
There was a problem hiding this comment.
As per todays discussion, it might be good to add some kind of header that will enable us to distunguish a skill generated integration from a custom one.
It is a flaky recognition system as the user might still remove the header, but better than nothing.
There was a problem hiding this comment.
Using x-apify-integration-origin: apify-integration-development-skill
4 participants
What
A new integration development skill for companies that want to build their Apify integrations. Has sections coversing Workflow automation platforms, agent harness plugins, SDK integration and AI framework integrations.
The root skill.md includes Apify info and commands the agent to fetch https://apify.com/agents.md for up to date Apify information
How I created the skill
I created design analysis md files on:
Then I merged the information into 1 skill file
Please let me know if any info is missing
@lukas-bekr could you please let me know if it is okay for me to merge the skills and replace the old sdk integration skill?
closes https://github.com/apify/integrations-team/issues/79