Pros/cons of using FE API library as integration test tool suite

Question

Wanting to open a discussion about testing approaches.

Context

I'm creating a new project and my main focus has been on efficiency and clean structure (not necessarily the most STANDARDISED code, but easiest to read, consistent, and quick to understand). Building my server-side code, and have mapped it from a loose outline of website UX designs. I want to create some integration tests in preparation for building FE.

I experimented with using newman/postman to automate some of these integration tests. Pros for this:

• Not reinventing the wheel, by that - the postman requests would exist anyway, it's not a whole new suite I'm having to build and maintain
• Consistency with project state, during the manual testing phase these postman requests would be updated so by the time integration tests happens, it's up to date automatically with the project state.

But had some issues with running. Then had the idea...

Why not build out the FE API library which connects to my server, and then use that as my testing suite?

• Easier to enforce contract testing as it can be coupled with unit testing on a real consumer
• Not a whole new suite I'm having to build and maintain, makes de-coupling near impossible and therefore reliability of testing increases
• Efficient use of time as this will be built anyway, the only additional coding would be scripts that schedule test calls
• Considering integrating the two repos (FE + BE) into a monorepo, using a management tool like NX (which can check for differences and only do builds / deploys when affected areas are touched). That way types can be consistent across touch points as they're both running of TypeScript.

Ideal conversation anchors:

• Experimented with something similar? How did it go?
• Considerations I haven't made which are likely to cause problems down the line?
• Anything easier to achieve the goal that I haven't considered?