Jetpack is a family of WordPress plugins plus reusable PHP and JavaScript packages. Start with the narrowest public interface that solves the problem; depending on the product, that may be a WordPress hook, a block extension, a REST route, or a published package.
- Choose an extension point and confirm that it belongs to the product you plan to extend.
- Build a first integration in a separate plugin so it can be activated, tested, and removed independently.
- Use the relevant guide for hooks, blocks, REST APIs, connection, Sync, or packages.
- Test the integration with the product active and inactive, then review its security, privacy, performance, and compatibility.
If your change belongs in Jetpack itself, use the contributor quick start. Its complete source guides preserve every document from the pinned monorepo docs tree while the shorter task pages keep current commands and decisions easy to find. Product-specific entry points live in the product catalog, while exact contracts live in Reference.
Public interfaces can still evolve. Declare the WordPress and Jetpack versions you test, preserve the incoming values of filters you do not own, and disable only the dependent feature when its required Jetpack component is unavailable so the rest of the site keeps operating. Fail closed for authentication, authorization, and other security decisions. Do not call an internal class merely because it is accessible in PHP.
