Best practices for submitting an app in the Developer Portal

Getting approved on the first review is possible. More often than not, delays are not because the integration is unfinished — they are because the listing, the install journey, or the demo video does not match what a Bob admin expects.

We will walk through the journey in three parts — the same order a customer (and a reviewer) experiences your app:

  1. Part 1 — Listing: how the app shows up in the Marketplace

  2. Part 2 — Install & uninstall: the path from Install to a working connection (and a clean disconnect)

  3. Part 3 — Certification video: proving the product works live

Official requirements: Submit for App Technical Review.

Part 1 — Your Marketplace listing

The first mistake partners make is treating the listing as an afterthought. From a customer’s point of view, the Marketplace page is the bridge between Bob and your product. If it looks thin or confusing, trust drops before they ever click Install.

Put yourself in a first-time Bob admin’s shoes:

  • Can they tell what the app does in the first sentence — without API jargon?

  • Do screenshots (or a short clip) show the real outcome, not just your logo?

  • Is support contact obvious if something goes wrong?

Complete every part of your listing

Your live listing draws from two different parts of the submission: App Listing Details and Tech Partner Overview form.

Complete both before you request review, and make sure each one contains the right information:

  • In the Developer Portal’s App Listing Details, complete the Value Statement and Functionality. Focus on the app itself and the value and functionality of the integration. This content appears in the live listing’s Overview section.

  • In the external Tech Partner Overview form, linked from the Developer Portal, include your company or solution description, value proposition, and the key features of your broader platform or product. This content appears in the live listing’s About section.

  • Prepare a customer user guide with install steps, setup in your product, what syncs, and who to contact. Write it for a first-time admin, not for your engineering team.

When you submit your app, it goes through two separate reviews:

  • Listing review: the general listing content and marketing assets used in the Overview and About sections.

  • Technical review: technical details, scopes, user guide, integration video, and related materials.

When should you submit a Security Review:
You may also go through a Security Review, which follows a separate timeline. You can initiate it as soon as you sign the Terms and Conditions, even before you have access to the Developer Portal, or at any later point, including after your app goes live. You can also initiate it more than once. For example, if your first review identifies a missing security requirement or standard, you can address the gap and initiate another review.

Whether you must pass the Security Review before launch depends on your app category:

  • For apps in the Payroll and Global Payroll categories, the Security Review is mandatory. Your app must successfully pass it before it can go live in the Marketplace.

  • For apps in all other categories, the Security Review is optional. You can complete it to qualify for the Security Certified badge on your app listing, but your app can go live without it.

Review everything together before submission so that the listing and review materials tell a single, consistent story. Compare the result with live apps in the HiBob Marketplace and aim for the same level of clarity.

Part 2 — Implement an install (and uninstall) that a new user can complete

Reviewers will install your app the way a real customer would — not the way you test it every day while already logged into your product.

Common roadblocks:

  • Install only works if the user already has an account and is signed in - make sure to support a non-happy flow

  • After consent in Bob, the user lands somewhere unclear and does not know what to do next

  • The path in your listing (Marketplace install vs your landing page) does not match what you actually demo

A smooth journey looks like this: Install → approve access in Bob → land in your product with a clear next step → the connection already shows as installed. If signup or login is needed after Bob, guide them; do not leave them guessing.

Uninstall is part of the same story. Show that when the app is removed in Bob, access stops on your side. Skipping uninstall in the demo is a frequent reason for another review round.

Tip: try a full install in a private/incognito window before you record. If you get stuck, a customer will too.

Part 3 — A certification video that proves the product

The video is how reviewers check that what you claim is real. A narrated tour of screens is not enough — they want to see the flows happen live on the same app you submitted, using your partner Bob company and demo data.

Keep the video short (about 5–6 minutes) and cover:

  1. Install the way customers will (including consent and return to your product)

  2. A real sync or core action — trigger it on camera

  3. The main flows that match the access you asked for (for example hire, update, time off — whatever you actually use)

  4. Uninstall, and a quick confirmation that the connection is gone

Ask yourself before you hit submit: does every permission on the consent screen show up as something useful in this video? If you asked for access you never demo, trim it for launch and add it later.

Also easy to miss: record on the same app you submit, and within the timeline in the docs (no later than 14 days after initial submission). Mixing unrelated testing on that app during review makes validation harder.

1