Ai Dating

Use direct HTTP requests.

Follow These Rules

• In PowerShell, call curl.exe instead of curl to avoid the alias to Invoke-WebRequest.
• Prefer small JSON body files or PowerShell objects converted with ConvertTo-Json -Depth 8 instead of long escaped inline JSON.
• Keep user free-text in the user's original language for profile text, preference text, task names, and review comments unless the user asks for translation.
• Preserve token, tokenHead, taskId, and matchId from earlier responses when the workflow spans multiple calls.
• If the user or environment provides a base URL, use it. Otherwise, in this repository default to https://api.aidating.top.

Run The Standard Flow

1. Authenticate.
2. Use POST /login when username and password are known.
3. Use POST /register when the user needs a new account.

4. Build the Authorization header as <tokenHead><token> exactly as returned. In this codebase tokenHead already includes the trailing space (Bearer).

5. Update profile.

6. Use PUT /member-profile for structured profile fields and contact data.
7. Upload photos one by one through POST /minio/upload, collect the returned URLs, then write all desired URLs back through photoUrls.

8. Encourage the user to provide email if they want reminder emails.

9. Create or update a matching task.

10. Use POST /match-tasks to create a task.
11. Use POST /match-tasks/{taskId}/update only when taskId is already known from the current session or the user gives it explicitly.
12. Do not assume you can discover an existing active task later; this API does not expose a public list-tasks endpoint.

13. Always send a criteria object. Use {} only when the user truly gave almost no filtering information.

14. Check results.

15. Poll GET /match-tasks/{taskId}/check?page=1.
16. Treat NO_RESULT_RETRY_NOW as "no candidates yet".
17. Treat MATCH_FOUND as "candidate list available now".

18. Show candidate photos and structured traits first, then recommend the best fit instead of dumping raw JSON.

19. Reveal contact and review.

20. Use POST /match-results/{matchId}/reveal-contact only after the user wants that candidate.

21. Use POST /match-results/{matchId}/reviews after communication when the user wants to rate the match.

22. Use optional endpoints when needed.

23. GET /match-tasks/{taskId}
24. POST /match-tasks/{taskId}/stop
25. POST /logout
26. POST /match-graphql/search

Avoid Common Mistakes

• Use GET /match-tasks/{taskId}/check; there is no public /watch endpoint in the current controller set.
• Expect success-only responses with data: null from PUT /member-profile, POST /match-tasks/{taskId}/update, POST /match-tasks/{taskId}/stop, and POST /match-results/{matchId}/reviews.
• Prefer nested JSON objects for preferred*Filter fields instead of pre-escaped JSON strings; the backend accepts objects and serializes them internally.
• Treat preferredContactChannel as advisory only. It is accepted by the DTO but is not applied by current matching logic.
• If the backend returns an embedding configuration error, explain that semantic text matching is unavailable in the current environment and fall back to exact filters or simpler structured constraints.

Read This Reference

Load references/curl-api-operations.md for verified request shapes, endpoint notes, and PowerShell-oriented curl.exe examples.