UETS API integration required in RFP: What is this integration and how should it be priced?

UETS services typically run on SOAP and WSDL standards rather than a standard REST architecture. You'll need to deal with XML signing, X.509 certificate validation, and the encryption algorithms mandated by PTT. Since the service documentation isn't very up-to-date, be prepared to spend serious hours debugging packet parsing in the staging environment.

When drafting your proposal, include these three conditions as special terms in the contract: 1) The legal protocol and application follow-up with PTT are entirely the client's responsibility. 2) The software team cannot be held liable for loss of legal rights resulting from UETS web service outages or timeout errors. 3) Integration testing will be conducted strictly through the test account provided by PTT.

We did a similar integration for a consultancy firm eight months ago. We finished the coding in 12 business days, but it took PTT a full 45 days just to approve the corporate agreement and whitelist the test environment IPs. Don't tie your delivery date to this bureaucracy in your proposal.

Definitely do not lump this into other modules in your proposal. Make it a separate line item under "UETS Official Integration Module". Price it at least double what you'd charge for a normal API integration because you'll end up having to manage most of the back-and-forth between the client and PTT yourself.

Is your client using their UETS account as an individual or as a corporate entity? Getting direct web service permissions for individual lawyer accounts can involve different procedures compared to corporate accounts—have they confirmed this with PTT beforehand?

Law firms want to pull every notification into the system automatically via API, but if the service fails to respond down the road and a court deadline is missed, the developer is the first person they'll blame. If you can't clearly define the limits of your liability in the contract, it might not even be worth getting involved in this at all.

On a project two years ago, we treated this integration like a simple SMS service and billed a small development fee. Later due to the security certificates PTT required, server IP changes and constantly changing service responses all the profit we made on the project went straight into tech support. When you quote them, make sure you definitely include an annual maintenance and service monitoring fee.

ptt api processes really move at a snail's pace. like definitely make sure to add a clause to the contract saying client-side approval processes are not included in the project delivery timeframe, otherwise they'll put pressure on you claiming the delivery is late.

Looking at it as a process, the picture changes. Most time waste accumulates in tasks waiting for approval.

This thread is archived. If you don't write this down from the start it leads to arguments later.

I went through the same thing.

I've been down this road, let me tell you. Payment schedules should be tied to project phases, not calendar dates.

Hope this helps.

Theres one point Im curious about. Implementing a change request process doesnt slow things down it speeds them up.

This is my opinion, I'm not claiming it's absolute truth.

I'll try it.

Noted, thanks.

Let me write how it's done in practice. Most time waste accumulates in tasks waiting for approval.

Good luck with that.

I feel the same way. Everyone rushing into uets api integration gets stuck at the same point.

Start with a small trial; don't commit to everything at once. Hope this helps.

To get into the details: When making decisions, write down the worst-case scenario too, not just the best.

Hope this helps.