Postman Generator Bundle Laravel Package

Getting Started

Reality check first: this bundle is archived, targets API Platform 1.x (Symfony 2/3 era), and has zero dependents. Only reach for it if you are maintaining a legacy API Platform 1 application — do not introduce it into a new project. For anything on API Platform 2.x/3.x, export OpenAPI (bin/console api:openapi:export) and import that into Postman instead; it is strictly better and still supported.

Minimal steps for a legacy app:

1. composer require vince/postman-generator-bundle (expect it to pull in Symfony 2/3 constraints — check composer why-not before committing).
2. Register the bundle in app/AppKernel.php (or config/bundles.php on early Flex Symfony 3.4 projects):

   new Vince\Bundle\PostmanGeneratorBundle\PostmanGeneratorBundle(),
   

3. Clear the cache so API Platform resource metadata is rebuilt: bin/console cache:clear.
4. Find the actual command name — the README is thin, so run bin/console list and look under the api-platform or postman namespace. Inspect the bundle's Command/ directory in vendor/vince/postman-generator-bundle/ to confirm options (output path, resource filters) before scripting it.
5. Run it and import the resulting JSON into Postman via Import → File.

First use case: generate a baseline collection so you stop hand-writing CRUD requests for every resource. Even if the output is imperfect, it gives you every endpoint, verb, and payload skeleton in one file — that's the value. Treat the generated file as a starting point, not a deliverable.

Implementation Patterns

Generate into a versioned path and diff it in PRs. The collection is JSON; committing it makes API surface changes visible in code review. Wire it as a Composer script or Make target:

postman:
	bin/console <generator-command> --output=var/postman/collection.json

Regenerate after any change to entity annotations, routes, or serialization groups — the generator reads API Platform metadata, so stale cache means stale output.

Parameterize immediately after import. Generated collections almost always hardcode http://localhost:8000 (or whatever your router.request_context resolves to). Create a Postman environment with baseUrl and authToken, then run Find & Replace across the collection to swap absolute hosts for {{baseUrl}}. Do this once; if you regenerate often, do it with jq in the same make target instead:

jq 'walk(if type == "string" then sub("https?://[^/]+"; "{{baseUrl}}") else . end)' \
  collection.json > collection.patched.json

Layer hand-maintained additions on top of the generated file. The generator knows about resources, not your auth flow, test scripts, or pre-request logic. Keep two collections:

• generated.json — regenerated, never hand-edited.
• workspace.json — your Postman working collection, where you paste in the auth folder, environment setup, and tests.

When the API changes, diff generated.json, port the new/changed requests into workspace.json. This avoids fighting merge conflicts in a machine-generated file.

Use the generator service directly when the command doesn't fit. The bundle is a thin wrapper around the api-platform/postman-collection-generator library. If you need to filter resources, change naming, or emit to multiple files, inject the generator service into your own console command and call it with the resource collection from API Platform's ResourceCollection — you get full control over grouping and don't have to fork the bundle.

Pair with Newman for smoke tests once the collection is stable: newman run workspace.json -e env.json in CI gives you a quick "does every endpoint respond" check for free. Add assertions in Postman's Tests tab (status 200/201, schema shape) — these survive regeneration as long as you keep them in workspace.json.

Gotchas and Tips

• Archived = frozen. No fixes for newer Symfony, PHP 8, or API Platform. If Composer can't resolve it, don't force it with --ignore-platform-reqs; you'll get runtime failures in the generator's reflection over API Platform metadata.
• Coupling to API Platform 1 internals. The generator walks ApiPlatform\Core\Metadata\Resource\ResourceMetadata and friends. API Platform 2 renamed and restructured these — the bundle will silently produce empty or partial collections rather than erroring. If your collection comes out with zero requests, that's the usual cause.
• Custom operations and subresources are likely missing. API Platform 1 predates the clean operation model; the generator typically emits standard CRUD from @ApiResource annotations. Manually add custom controllers, subresource routes, and filter parameters (pagination, order[...], search filters) to your workspace collection.
• Auth is not inferred. No security configuration is read, so generated requests have no Authorization header. Set it collection-wide via Postman's Authorization tab at the collection level so every request inherits it.
• Request bodies reflect serialization groups loosely. Don't trust generated payloads as valid — they may include read-only fields or omit required denormalization groups. Validate one POST per resource manually before trusting the rest.
• Run after cache warmup, not before. Metadata is cached; generating right after a code change without cache:clear yields the previous API shape. Make cache:clear a dependency of your postman target.
• Large collections are slow in Postman. If you have 50+ resources, split by domain (inject the generator with a filtered resource list in a custom command) rather than importing one 5MB JSON.
• The command name and options are undocumented. Read vendor/vince/postman-generator-bundle/src/Command/*.php — it's a few hundred lines and tells you exactly what's configurable (output path, base URL, maybe resource filter). Faster than guessing.
• Don't build process around it. Because it's archived and unmaintained, anyone joining the team will need to reverse-engineer it. Document the make target and the "generated vs. workspace" split in the repo README so the workflow survives without you.